| Author |
 Topic  |
|
|
RomanMGC
New Member
4 Posts |
 Posted - Feb 24 2015 : 04:35:32 AM
|
Hi!
There is an issue which exists for a long time.
When I type a name of a variable of some our custom type and then type a dot, VA converts it to ->. It wouldn't be a problem if I could easily and robustly undo it.
The issue is that the undo doesn't work:
if a name of a variable is immediatly followed by some other text (that could be a closing bracket, or even a hidden new line symbol), than when I undo the conversion with Backspace button VA _removes_ some piece of code that comes immediately after the typed dot symbol, instead of undo. This happens every first time I type a new line of code. This happens because after the conversion some piece of text immediately after the typed dot symbol stays selected!
Imagine this situation - I want to write the line "if (arr.size())" :
1) I type "if (" and VA adds the closing bracket ")",
2) then I type "arr." inside brackets and VA converts dot to ->,
3) then I press Backspace and VA removes the closing bracket!!!
This very disappointing thing lasts for at least a year and still isn't fixed in the last release 2059.
None of the options can solve this problem.
Visual Studio Prof 2012
C++
Hope it will be fixed! |
Edited by - RomanMGC on Feb 24 2015 04:39:29 AM |
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Feb 24 2015 : 6:48:24 PM
|
I am seeing the same effect here. Thank you for the clear description.
case=88071
I don't think anyone has ever reported this before, certainly I cannot find a bug report for it, so I have put in a bug report.
I can see why this is happening with the if statement, since VA inserted the closing bracket, which can also be undone with backspace. Do you have an example where a newline or something not inserted by VA is being removed? Backspace to undo the conversion should normally work.
When you are trying to undo the dot to ->, was VA wrong to do this conversion? There will obviously be times when this was correct, but you still wanted dot. I am just making sure this is the case here. |
zen is the art of being at one with the two'ness |
 |
|
|
RomanMGC
New Member
4 Posts |
Posted - Feb 27 2015 : 09:16:10 AM
|
1) Other cases of removing happen quite rarely. At this moment I can't figure out a reproducable solution. But I will try...
2) We have our own template array class. It doesn't have an overloaded operator->. But for variables of this type VA always converts dot to -> . So yes, VA is wrong here. But we have got used to it )
I've just found an interesting behaviour:
- if the option "Convert dot to -> if operator-> is overloaded" is cheched then VA does incorrect conversion,
- if the option is unchecked then VA doesn't do incorrect conversion  |
Edited by - RomanMGC on Feb 27 2015 09:22:06 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Feb 27 2015 : 11:46:02 AM
|
If you come across another reproducable case I will be very interested to see it and to test it.
For your template class, if you show VA View, then place keyboard focus back into the editor, and now hover the mouse over a variable of this class type, or the class its self, what is shown in the bottom half of VA View? More specifically, is the class shown as having an overloaded -> operator or a base class that might be giving it an inherited -> operator?
The VA settings clearly indicate that VA thinks your class has this operator, so the question is, why does VA think this? |
zen is the art of being at one with the two'ness |
|
|
|
RomanMGC
New Member
4 Posts |
Posted - Mar 02 2015 : 04:26:20 AM
|
quote:
Originally posted by feline
The VA settings clearly indicate that VA thinks your class has this operator, so the question is, why does VA think this?
Oh, yes, that's it! I totaly forgot about it. Our class does inherit from a class with overloaded operator->:
template<class T>
class the_best_array_ever : protected boost::shared_ptr<T>
...
Anyway, it is inherited as protected - and the overloaded operator-> can't be used outside the class scope. So, I would suggest for VA not to do the conversion. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Mar 02 2015 : 12:30:28 PM
|
That makes sense, I am seeing the same problem here now I know what to look for:
case=88190
Out of interest, why have you used a smart pointer as a base class if you don't want to access the operator-> function? |
zen is the art of being at one with the two'ness |
|
|
|
RomanMGC
New Member
4 Posts |
Posted - Mar 03 2015 : 03:42:38 AM
|
quote:
Out of interest, why have you used a smart pointer as a base class if you don't want to access the operator-> function?
It is used as internal container :) But would prefer to incapsulate it as member rather than inherit it...
Well, it's great that we have made it clear with my issue.
Hope it will be fixed in the next release |
Edited by - RomanMGC on Mar 03 2015 03:44:48 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Mar 04 2015 : 12:17:42 AM
|
Ah, that makes sense, thank you. I was wondering what was happening here.
Unfortunately I don't yet have an estimate for either bug report from this thread. We have quite a few open bug reports and feature requests, as I am sure you can anticipate, so we cannot always get to new bug reports as quickly as we would like. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Incorrect undo for "dot to -> conversion"
