|T O P I C R E V I E W
||Posted - Sep 26 2015 : 05:34:31 AM
Hello. There is an old-new annoying bug in the actual VAssist version. When I autocomplete some word in a string, VA overwrites next word with found suggestion instead of to insert it before one. It's very confusing and waste much of my time.
|30 L A T E S T R E P L I E S (Newest First)
||Posted - Mar 17 2021 : 08:09:25 AM
There is a setting to control this. Currently you need to edit the registry to set this setting, but once set, it will stay set. It is explained here:
We are considering adding this option to our options dialog for easier access:
||Posted - Mar 17 2021 : 05:27:50 AM
I would like to support this feature request. A setting in the options dialog would indeed be very much appreciated.
||Posted - Mar 16 2021 : 11:18:51 PM
So now is 2021, its been... 6 years?
do we have the setting button somewhere to let [enter/tab] auto-complete not eat the existed next words?
||Posted - May 15 2020 : 10:44:09 AM
We are also aware that making these settings more available would be helpful, but want to do this without overwhelming our options dialog:
||Posted - May 15 2020 : 10:40:43 AM
Apologies for not having Atmel registry keys listed in the documentation, I am adding them now.
eddieparker, these are the keys for Visual Studio. For Atmel the values and types are the same, but the keys are stored in a different place in the registry.
Steve, you want to close Atmel and then edit:
HKEY_CURRENT_USER\Software\Atmel\Whole Tomato\Visual Assist X\AtmelStudio7\CompletionOverwriteBehavior
This key already exists on my Atmel system, so I would expect it to already exist on your system as well. It is type is DWORD (32-bit) Value.
||Posted - May 14 2020 : 9:02:28 PM
I agree with you Steve. I can understand that for Whole Tomato this setting is a default and changing a default might be bad, but it is unfortunate that this destructive behaviour is the default, and not easily fixed without the registry setting.
If it helps, I keep a regkey on my DropBox with these contents, so I can apply it on new machines:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\VANet15]
[HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\VANet14]
||Posted - May 14 2020 : 8:01:54 PM
This really does need to be added to the GUI, and it should take this much teeth pulling to get it there.
I am using VAssistX in Atmel Studio. Unsurprisingly, there is no existing entry in my registry that has what could be clearly seen to be a <IDE Spec> for Atmel Studio, and there's nothing in your list of acceptable <IDE Spec>s for it. So right off the bat, I'm left to hack at it. Not cool.
Secondly, it is not clear from your "article" on modifying the registry how exactly it should be entered. Is it added as a Key or a DWORD or something else. If its a Key, and I supposed to set the default value for the key. Why not be explicit about this. I don't want to hack at your options and play a guessing game on why it's not working.
There's just no reason for this kind of confusion y'all. Make it an option in the GUI and be done with it. All this nonsense for such bad default behaviour and poorly documented "solution" is infuriating.
||Posted - Aug 15 2018 : 3:01:12 PM
As to your specific questions / answers:
At my work, there is exactly one developer who uses VA at all - me. And I am 50% of the C++ development force here. The other dev is an old-school C developer, and things like classes and namespaces and the intricacies of templates or even of smart-pointers and the like - are only understood so well, and only used to a certain extent. So having a tool like VA which helps manage the complexity of the more sophisticated applications of C++ language are not of interest. In fact, I believe he uses Notepad++ as his preferred source editor, and the syntax highlighting available there is all he desires.
If I worked at a larger organization? Who knows? It is my anecdotal experience that most software engineers aren't into C++, most software houses do not use C++, and even those who do largely are skittish about what new language features they allow their devs to incorporate - still largely insisting on something akin to C++ 98 or even prior to that.
I have the great pleasure to choose my own tools, and VA has been an integral part of our success here since I started using your product - over a decade ago - maybe much longer? I lose track of time.
For my 2c - I would very much wish to encourage case=79188 - even if this registry setting is never made into a top-level configuration option - being able to export and later import my user-settings (or better, take my rant about user-settings to heart and move this and all other user-settings out of the registry and into my user account's documents\VAX\ folder or something similar).
It is - mildly insane - that any modern software cannot trivially be reinstalled or moved to a new machine - along with all of my customizations of it - seamlessly.
||Posted - Aug 15 2018 : 2:54:11 PM
To get on my personal soap-box for a moment:
Windows & MS got it wrong. Badly, deeply, deplorably, regrettably, foolishly, wrong; from the beginning.
The registry is and was and remains a TERRIBLE place to store software-configuration information that is truly related to the user, and not the per-machine instance system wide settings. Those make sense in the registry, and should not normally be user-editable, and should not normally be something one would want to migrate to any other machine. They should be - machine specific settings and configuration data for applications and the OS.
User configuration information should ALWAYS have been stored in the USER's space - visibly - in a simple text editable file format that migrates with the user (and for per-user but machine-specific configuration data, well, probably the registry is fine - that would need to be carefully considered on a case-by-case basis).
When MS moved from .ini files to the registry - they were deeply foolish to not simply insist that .ini be stored in user space, and system settings in reg space. Ah well. Stupidity rules the planet, for the most part.
||Posted - Aug 14 2018 : 2:52:43 PM
We do collect some high level telemetry, but nothing this detailed. We are considering a page for the registry key settings, but don't want to cause more problems than we solve.
As for exporting VA settings more easily, this is something we are considering:
||Posted - Aug 14 2018 : 2:17:51 PM
I don't know the number of people that actually use the settings, but when I send out a mail telling people about the setting, I tend to get hordes of replies thanking me for solving an annoyance they have. Inevitably they forget it, have another machine, reformat, etc, and then they come and ask me for the setting again.
Does VAssist not do any telemetry? It might be neat to see how many people in the wild have certain settings enabled or regkeys on. Although the discoverability of the regkeys might not make any statistics you get super useful.
Lastly, I've never written a visual studio plugin, so salt my question appropriately: can't Visual Studio synchronize your settings via it's roaming profile stuff? I'm not sure how hard/easy that is, but that'd be nice for these sorts of settings.
Thanks again for taking the feedback. I do wish there was an easier UI for this, even if it was buried under an "Advanced/Experimental/These-Might-Change" fold-out.
||Posted - Aug 14 2018 : 12:38:34 PM
Mordachai, all of the current registry keys are listed and explained here:
which also helps to explain why we are not rushing to put all of them into our options dialog, it would add quite a lot of options that most people, most of the time, don't want to change. But it does seem that this specific setting is being used more than I had realised.
The specific request for adding this setting to our options dialog is:
one reason for not rushing to add this setting to the options dialog is that this change only works in C/C++, not C#. Also, it is not heavily tested, and we know that sometimes it does not work quite as expected.
How widely is this being used in your companies?
As for the more general question of what to do when your machine gets re-installed, sadly, I have resorted to keeping a record of all of the different settings I need to configure in the software I rely on, so that I can get things back to working correctly when I have to move to a different machine or reinstall. It feels like there should be a better solution, but across so many different programs, and different options, I am never going to remember all the useful changes I have found and made.
||Posted - Aug 14 2018 : 09:41:32 AM
Just adding my two cents: this feature is sort of tribal knowledge around my workplace and people tend to write to me to remember which cryptic registry key they need to set after they hear about it from someone else, or their machine gets reinstalled, etc.
||Posted - Aug 14 2018 : 08:22:18 AM
The setting is very stable / reliable - but how does one know about it if one isn't already subscribed here?
How about "how do I find this the next time I do move machines?"
I probably stumble onto the bad behavior - struggle for a while - remember that "yeah, isn't there some registry fix for this" - then google a bunch, maybe I hit on this - maybe I don't.
Or I can squirrel away some document about this someplace... where? under what title? how will I know to look there the next time I move machines and have to rediscover this problem?
Do you have a help-topic in your software that details all such hidden registry work-arounds? Or do I literally have to come to this thread?
||Posted - Aug 14 2018 : 06:44:34 AM
We are still considering adding the registry key settings to the VA options dialog, but this is not currently a high priority.
Have you recently moved machines? Once set, these settings should be stable and reliable.
||Posted - Aug 13 2018 : 7:58:29 PM
Please, please, please, add this to the GUI!!
||Posted - Dec 05 2017 : 10:13:36 PM
Yep - all set until VS 16.x lol - whatever is next in the VS world. Changing this was easy coming back to this thread.
Thanks for a great product and all of your efforts to keep us grumpy coders happy :D
||Posted - Dec 05 2017 : 5:15:58 PM
Apologies for this. We are looking to make moving your registry settings from one version of the IDE to another version a bit more straight forward:
At least you have now changed the setting for VS2017, and VA is back to working how you want and expect.
||Posted - Dec 05 2017 : 11:35:10 AM
Addendum: I have transitioned our main products to use VS2017, and my defaults from VANet14 did not come over. So my CompletionOverwriteBehavior went back to (0). :(
I would really prefer if such a setting were retained for each new installation of VA / VS.
I would really prefer it if such a setting were given an interface in VA settings config as well.
It's a really annoying bug for folks like myself, and I assume for Adequat - for whom having our code overwritten as we're typing something is unconscionable, and unhelpful in the extreme.
||Posted - Aug 15 2017 : 4:13:24 PM
yes - that is always the issue with "smart" - one person's 'smart' is another person's 'dumb' ;)
||Posted - Aug 15 2017 : 3:49:26 PM
Thank you for the update, I am glad this is working for you.
The default behaviour attempts a basic "smart" replacement option, but this isn't always what people want. There is something to be said for simple rules of behaviour, since they are easier to explain and understand. From experience, the current behaviour is complex enough that it's not always clear to people what is happening, or why.
||Posted - Aug 15 2017 : 3:28:41 PM
This feature is working reasonably well for me with the registry setting to "never overwrite" (or always insert).
I would still advocate for this to be a config setting available in the settings panel for VA.
I would also advocate for some "smart" replacement options as we've discussed in the past.
||Posted - Aug 15 2017 : 1:41:40 PM
Adequat, when preparing to edit the registry, are you making sure that all instances of the IDE have been closed? The only reason the setting should ever be reset is if you have an instance of the IDE open, and then close it. VA saves out its settings on exit, so if the instance had the "old" setting, then it would save this out when closed, over-writing your change to the registry.
I have just double checked, under Windows 7, VA 2223 and VS2017, specifically VS 2017 ver 15.2 (26430.16) Release, the registry key is not being reset for me, I change it and it stays changed.
If you are closing all instances of the IDE, then the next step is to ask you to run Process Monitor, and set this to monitor this registry key, so we can find out what process is changing it back. If it is the IDE, and VA, I have no idea why or how come, but it would certainly explain the problems you are seeing.
Mordachai, is this setting working as expected for you, now you are changing the registry key for VS2015?
||Posted - Aug 15 2017 : 09:21:34 AM
Ah - I was running 2015.
||Posted - Aug 14 2017 : 6:02:20 PM
No problem under Visual Studio 2015.
The problem only happens under Visual Studio 2017 (15.2)
...but when I set CompletionOverwriteBehavior to 1
(in HKEY_CURRENT_USER\Software\Whole Tomato\Visual Assist X\VANet15)
Then when launching Visual Studio 2017, the value CompletionOverwriteBehavior is reset automatically to 0 !!!!
So, now you know where the bug is!
And BTW, I don't see a single reason why this parameter should default to 0 and not 1!
||Posted - Aug 14 2017 : 5:23:59 PM
Having set the registry (as explained earlier in this thread) mine inserts always - even under those conditions.
||Posted - Aug 14 2017 : 4:11:52 PM
See picture below.
1) is the start situation
2) My purpose is to end up with BCanUndo(foo());
that is, what you see in #5
When I start to type 'BC' a popup opens, and I am offered the choice to select BCanUndo, which is good (BCanUndo being an identifier among thousands). See #2 on the picture.
3) But when I press Return, 'foo' gets erased, and I get what you see in #3
4) I would expect, instead, what you see in #4, so that I can soon follow with #5.
Needless to say, this bug is a workflow breaker, and an error input.
||Posted - Aug 12 2017 : 2:27:23 PM
Are you able to reproduce this? Clearly something is going wrong, but without some sense of the trigger, this is going to be hard to pin down properly.
||Posted - Aug 12 2017 : 1:03:30 PM
I confirm there is something wrong for a couple of weeks (last version?). That is, the registry option "never overwrite text immediately right of caret" fails more than sometimes, which is pretty boring.
||Posted - Jun 06 2017 : 4:20:20 PM
If and when this starts happening again, can you keep an eye out for a case where you can reproduce this on demand?
Backspace to remove a word, and then starting to type again made sense as a possible trigger, but clearly there is more to this than just that.