| T O P I C R E V I E W |
| MrDoomMaster |
Posted - Oct 24 2007 : 1:43:29 PM
IDE: Visual Studio 2005
VAX Build: 1614
In an empty CPP file, type the following (without quotes):
'else'
Notice how after you type the last 'e', the suggestion box goes away (this is the intended behavior).
Now try this:
'try'
Notice how after you type the 'y' character, the suggestion box does NOT go away, which is very annoying. 'if' and 'void' both have the same behavior as 'try' (as described above). So far I think 'else' is the only reserved identifier that makes the suggestion box go away. The suggestion box should go away when full words have been typed (this is the legacy behavior)
Expected behavior:
All suggestion boxes should have consistent behavior for all built-in C++ identifiers. |
| 23 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Nov 11 2011 : 8:43:45 PM
There is no simple right or wrong answer here, as we all recognise.
Just because an option is in our options dialog does not mean that it gets discovered, understood or used. We get a steady stream of support requests asking about settings that are already in our options dialog, or sometimes in the IDE options dialog.
The idea of an advanced options page is tempting, but it can be a small step from there to merging these options into the main options dialog, and taking a big step towards options overload. There are currently 31 entries in the Registry settings section of the FAQ, so if we suddenly added 25+ options to our options dialog, this would be quite a lot. |
| StefanEgo |
Posted - Nov 10 2011 : 06:48:41 AM
I'd like to second MrDoomMaster on his point of even being able to configure VAX "advanced" settings via the config menu instead of having to manually edit the registry.
The problem I'm having with editing registry settings is that I first have to learn that the registry setting exists. If I had an entry in the config menu, I'd easily recognize any configurable setting immediately.
I do understand the tendency to keep the configuration pane as simple and clean as possible and tbh that was one of the reasons we actually started using VAX in the first place. Being overstrained with too many settings (especially for new users) can be very counterproductive, since it's hard to get focused on the important ones.
However, if I may suggest a solution:
Why not add a button to the configuration panel: "Show advanced settings".
When the user clicks on that button, additional entries are listed in the configuration panel containing those settings which are useful for specific use-cases/users but most likely not for the majority of your customers.
That would pave the way to make other settings configurable, too (like /\\-behavior with the auto-include-header-refacotr method, including/excluding regions in VAX outline view, etc.). |
| MrDoomMaster |
Posted - Nov 04 2011 : 10:10:03 PM
I don't want to give you a hard time about this, I know that my opinion is only one of hundreds you have to consider, and no two will be the same.
This is the only complaint I really have after having used VAX for over 6 years, so that's quite an accomplishment you've made. You do a great job, VAX is a fantastic product and one of my most valued development tools in my tool belt.
Whatever is decided I will respect it. At the end of the day at least the option exists and is configurable, be that through the GUI or the registry editor. |
| feline |
Posted - Nov 04 2011 : 9:45:05 PM
There is a balancing act here, and I agree, the correct balance is far from obvious. No options, while brilliant from a support and testing point of view, is clearly fairly useless. At the same time, we try to keep the number of options to a small but sensible number.
One complication is the way VA has to be written, we do a lot of working behind the IDE's back, which makes options more complex than normal.
None of which alters your valid points. Changing existing behaviour has to be done slowly and carefully, since this is a good way to upset people, and cause problems.
Relying on feedback and requests is a poor method of working out what things to do, but it does offer some guidance, plus I try to get to the "why" behind requests, since sometimes this is more informative, and suggests other directions or approaches to solving the underlying problem. |
| MrDoomMaster |
Posted - Nov 04 2011 : 5:59:16 PM
quote:
Originally posted by feline
I am not seeing a case to add this to our options dialog, so I have just put in a feature request for this:
case=62474
You make a fair point, but at the same time, a forum search shows only 3 threads have ever referenced the FAQ for this option, so it is not something a lot of our users seem to be looking for.
We have limited resorces, and don't want to end up with a massive number of exposed options. I spend a lot of time changing settings in Visual Studio, and I regularly still get "lost" trying to find the option I want. Having a massive number of exposed options is not automatically helpful.
If you don't provide the options the only other alternative is for users to either deal with the inflexible behavior or hack the registry. So obviously when it comes down to this, "having too many options" may just be the nature of the beast. If you really wanted to make VAX options clean, just remove everything! Then it will just be beautifully blank & simple, and I'll keep regedit open 24/7!
All jokes aside, you've taken legacy behavior and changed it, normally options are provided to bring back the old behavior.
Relying on the references to the issue may not be a reliable statistic, since most people I know usually just complain about it but never find the time to report it. That's probably 90% of the people I've worked with.
Thanks for the feature request submission, I look forward to waiting another 4 years for this to be finished ;) |
| feline |
Posted - Nov 04 2011 : 5:28:06 PM
I am not seeing a case to add this to our options dialog, so I have just put in a feature request for this:
case=62474
You make a fair point, but at the same time, a forum search shows only 3 threads have ever referenced the FAQ for this option, so it is not something a lot of our users seem to be looking for.
We have limited resorces, and don't want to end up with a massive number of exposed options. I spend a lot of time changing settings in Visual Studio, and I regularly still get "lost" trying to find the option I want. Having a massive number of exposed options is not automatically helpful. |
| MrDoomMaster |
Posted - Nov 02 2011 : 3:46:13 PM
Been about 4 years since I posted this, but I still see no check box to represent the CloseSuggestionListOnExactMatch registry value.
Please add this. It's been 4 years guys, come on. |
| MrDoomMaster |
Posted - Dec 21 2007 : 2:52:39 PM
quote:
Originally posted by feline
We are trying to keep the options dialog fairly simple and basic.
Plus it is not quite as simple as it might be, since some parts of the options dialog work differently depending on which IDE you are sitting in. Not a big complication, but it is a factor.
Well it's not all about how easy or hard it is to implement. The big thing that bothers me is that if you continue to exclude features like this from the GUI, users will be paying for a product and more than likely not ever be aware of these features. Since this product isn't free, that is all the more reason to add these features to the GUI [you're being paid for these things]. If I wasn't an understanding fan of VAX, I'd probably say that leaving out fundamental GUI features is very lazy. Again, since I'm understanding, I know that you guys are very busy and are doing your best to make the customers happy. However, completely refusing to do these things is, in my opinion, unacceptable. I'd rather it take a year to happen than not to happen at all. |
| feline |
Posted - Dec 21 2007 : 2:46:46 PM
We are trying to keep the options dialog fairly simple and basic.
Plus it is not quite as simple as it might be, since some parts of the options dialog work differently depending on which IDE you are sitting in. Not a big complication, but it is a factor. |
| MrDoomMaster |
Posted - Dec 21 2007 : 2:43:22 PM
quote:
Originally posted by feline
Have you considered getting VA configured how you want on a single PC and then exporting the complete VA settings? You can then just run / import the registry file to get all of the settings in one go.
VA Options -> Performance -> Export Settings
I didn't know this (before I used to actually visit the registry key manually and export it through regedit). However, I still believe there should be a GUI option for this, since as I said before it doesn't take long to add.
Thanks for the work-around though, this is definitely better than playing hide and seek with the registry hive. |
| feline |
Posted - Dec 21 2007 : 2:32:32 PM
Have you considered getting VA configured how you want on a single PC and then exporting the complete VA settings? You can then just run / import the registry file to get all of the settings in one go.
VA Options -> Performance -> Export Settings |
| MrDoomMaster |
Posted - Dec 21 2007 : 11:01:18 AM
quote:
Originally posted by sean
There will be an FAQ post about it. No UI option yet - but that could change depending on ongoing feedback about the listbox behavior changes. Depends also on whether we come up with a satisfactory implementation of the idea I had proposed.
Would be really nice to get a GUI option for this feature. I've done GUI work before in many APIs, and adding a checkbox control is not difficult. This should be no more than 1 hour of someone's time.
I would appreciate having this GUI option in the next build. While I am extremely grateful that the feature is now available, it is very annoying to have to sift through registry trees on each PC I install VAX on and toggle this registry key myself. |
| sean |
Posted - Nov 10 2007 : 5:39:02 PM
There will be an FAQ post about it. No UI option yet - but that could change depending on ongoing feedback about the listbox behavior changes. Depends also on whether we come up with a satisfactory implementation of the idea I had proposed. |
| MrDoomMaster |
Posted - Nov 10 2007 : 5:14:05 PM
quote:
Originally posted by sean
We decided not to implement what I had proposed - at least not at this time. Build 1616 does have support for making the listbox close automatically if what you have typed is an exact case-sensitive match for the selected listbox item.
This option has no UI - you will see it in the registry with the name "CloseSuggestionListOnExactMatch"
The default value is 00.
Set to 01 to have suggestion lists close for example when you type try even though the relevant TryEnterCriticalSection is also listed.
Thanks for the change. Why isn't there an option for it? I guess it isn't permanent? |
| sean |
Posted - Nov 10 2007 : 3:05:16 PM
We decided not to implement what I had proposed - at least not at this time. Build 1616 does have support for making the listbox close automatically if what you have typed is an exact case-sensitive match for the selected listbox item.
This option has no UI - you will see it in the registry with the name "CloseSuggestionListOnExactMatch"
The default value is 00.
Set to 01 to have suggestion lists close for example when you type try even though the relevant TryEnterCriticalSection is also listed.
|
| MrDoomMaster |
Posted - Oct 25 2007 : 1:23:11 PM
quote:
Originally posted by sean
I agree that this scenario makes you type more with VA than without. But I think that's where the focus should be - typing, not the presence of the listbox.
Does it bother you that the listbox doesn't go away or that you have to press enter twice?
That is, if you didn't have to press enter twice, would the presence of the listbox still bother you?
What if in the try example, pressing enter on try was smarter?
Like, if you've already typed the full suggestion (and other suggestions are present), pressing enter on try closes the listbox and inserts the linebreak (unless the suggestion was a snippet)?
The fact that I have to press enter twice is what bothers me. I apologize as I should have been more specific I suppose. The solution you present here is perfect IMHO. |
| sean |
Posted - Oct 25 2007 : 1:07:47 PM
I agree that this scenario makes you type more with VA than without. But I think that's where the focus should be - typing, not the presence of the listbox.
Does it bother you that the listbox doesn't go away or that you have to press enter twice?
That is, if you didn't have to press enter twice, would the presence of the listbox still bother you?
What if in the try example, pressing enter on try was smarter?
Like, if you've already typed the full suggestion (and other suggestions are present), pressing enter on try closes the listbox and inserts the linebreak (unless the suggestion was a snippet)?
|
| feline |
Posted - Oct 25 2007 : 08:23:11 AM
Listboxes have been changed in the 16xx builds, which is where this problem is coming from. If you add the local variables:
int elseOne, elseTwo;
and now try typing "else" then the suggestion listbox remains visible. So the reason it is closing for "else" is actually that there are no other suggestions.
I have put in a bug report, requesting an option to use the old listbox behaviour instead of the new listbox behaviour:
case=9547 |
| rhummer |
Posted - Oct 24 2007 : 5:17:36 PM
Well, crap I unchecked the wrong option. I am seeing it to with tthat disabled. Sorry about the confusion. :( |
| MrDoomMaster |
Posted - Oct 24 2007 : 5:00:51 PM
 |
| rhummer |
Posted - Oct 24 2007 : 4:14:39 PM
Hm, I'm not seeing this behavior, and I disabled "Include VA Snippets in listboxes."
typing try gives no listbox, so everything is just fine. Yes I'm using 1614 also, so that's very odd.
With the check enabled it does hang around since it is a VA Snippet entry and I do expect it to hang around in that case. |
| MrDoomMaster |
Posted - Oct 24 2007 : 3:58:33 PM
"Include VA Snippets in listboxes" is unchecked for me. It's more than just "odd" behavior, it is wrong behavior. The legacy behavior would HIDE the suggestion box if it matched something exactly. This feature was changed and I don't like the way it is now.
To further prove my point in that it can be annoying, I'll provide an example. Say I'm going to type a try/catch block:
try
{
}
catch( ... )
{
}
When I type 'try', the suggestion box does NOT go away which means I have to press RETURN twice to make a new line (first return makes the suggestion box go away, the second inserts the carriage return). The old 1559 build would hide the suggestion box after typing the 'y' in 'try'.
I would have at least expected a check box somewhere to switch between the old and new behavior. You guys may not see this as a bug, however I see it as a bug and it's quite a big disappointment that I don't have any other choice but to either deal with the problem or stop using VAX entirely.
If there is some tricky option I'm not seeing to toggle this feature then I apologize for overreacting. However at this point in time I'm not seeing any obvious way to change the behavior. |
| feline |
Posted - Oct 24 2007 : 3:46:15 PM
For me "try" and "if" are both shortcuts for snippets. Since I have snippets turned on, the listbox has to stay visible, so that I can accept the snippet in the list.
Are you seeing snippets suggested at this point?
I agree the behaviour is "odd", but at least on my system, with my current settings, there is a good reason for it. |
