| Author |
 Topic  |
|
|
rittjc
Ketchup Master
USA
84 Posts |
 Posted - Jun 14 2005 : 10:47:34 AM
|
| Is there a way to put up a simple dialog on install that allows the user to force VAX Updates/Installs to put it's hand on a bible and take an oath before God almighty that it will not touch VS key bindings no matter how strong the compulsion it has to do so? Since the 2003 days I have always answered NO (there is no "PLEASE GOD NO!" button or I would hit it multiple times) to all three prompts asking if VAX should destroy VS settings but it still can't resist the temptation to change our key bindings? What about NO three times ever means YES? Very, very frustrating. I know it changes them because my F7 compile function (and others) is(are) no longer assigned just like the VS defaults immediately after a VAX update. |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 14 2005 : 3:40:14 PM
|
what IDE, etc, are you using? i have added various custom keyboard shortcuts to vs 2003 and when i say "no, leave it alone" when installing VA upgrades the keyboard shortcuts are left alone.
there was a bug with installing VA 14xx on vs2005 where it reset keyboard shortcuts when it shouldn't have, but this has been fixed in 1413.
VA has to do some resetting due to a problem with the IDE its self. |
zen is the art of being at one with the two'ness |
 |
|
|
WannabeeDeveloper
Tomato Guru
Germany
775 Posts |
Posted - Jun 14 2005 : 4:51:56 PM
|
quote:
Originally posted by feline
VA has to do some resetting due to a problem with the IDE its self.
I think MS fixed that bad VSIP-behaviour in VS 2005. AddIns may now add/delete Toolbars/Menus without wreaking havoc on every cutomized User-Settings...
But that behaviour still exists in VS .NET 2002/2003, and there's nothing we can do about it. With VS 2005 on the horizon, I strongly doubt that MS will change the VSIP within VS .NET 2002/2003.
Lots of AddIns do that without even asking you, giving you no chance to even answer "NO!", not to talk about any chance to say "PLEASE GOD NO!"  |
 |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 14 2005 : 10:23:00 PM
|
Might outta check that again with VS2005. I am using VS2005 Beta 2 (Feb/Mar) so I am certain it is not fixed. I don't know if it is or is not a VS problem, maybe it is. I have added my own addins in VS2005 (Beta 1) in the past and it didn't toss my keys. My addin's were very simple but I don't think just adding the addin itself deep six'es the key bindings, but admittedly, I am no addin/VS expert so you can take that for what it's worth.
I don't know if this matters or not but in upgrading/updating, most users don't want anything changed by the upgrade, not toolbars, menus, keys, nothing. It seems to me that updates would be "ultra-benign" and not even prompt the user for updates. But if they must, at least have a "leave it like it was" checkbox on the install dialog that spares us the prompts we want to make sure we always answer with NO. JMTCW. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 15 2005 : 3:12:29 PM
|
which version of VA have you been using? there was a bug where VA reset the keyboard shortcuts when installing on vs2005 beta 2 which has been fixed in 1413.
with regard to resetting the IDE VA introduces its own menu and toolbar, along with adding default keyboard shortcuts if possible. i don't know for certain, but i suspect VA would not reset the IDE unless necessary. this is a regular source of questions and comments. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 15 2005 : 5:33:10 PM
|
| 1413. I wouldn't dare post problems unless I was using the latest. I find that pretty inconsiderate though you folks probably see it all the time. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jun 15 2005 : 8:03:54 PM
|
Resetting of shortcuts is very annoying. We aren't trying to do it.
We have 1413 installed. We start VS2005. Keyboard mapping scheme is "Default."
We [re]assign F7 to File.OpenFile in Global context. We test F7. It opens the dialog we expect.
We exit VS2005 and resinstall 1413. We answer "no" to the rebuild/reset prompts.
We start VS2005. F7 still opens the dialog we expect. It's still assigned to File.OpenFile.
We exit VS2005 and reinstall 1413. We answer "yes" to rebuild/reset prompt for VS2005.
We start VS2005. F7 is not assigned to File.OpenFile.
What differs for you?
What is your key mapping scheme when you start? |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 16 2005 : 09:38:44 AM
|
Looks like you might have missed the point. You have to remember, users like their settings the way they were. I think I speak for most people on that. They donG??t want to change them so they donG??t click YES (or shouldnG??t), they instead click NO (or should). But clicking NO gets the same results as clicking YES. It whacks the settings regardless. Users normally DONT want to change key bindings so they DONT check YES, the DO (or should) check NO (and why I jokingly said they are so adamant about it, it needs to be worded "PLEASE GOD NO!" instead). No one in their right mind would want to change key assignments just because they installed fixes to VA.
This may be a tad philosophical, by why, using the furthest stretch of the imagination, would someone, anyone, anywhere, anytime, have a reason to want to change key assignments at the exact same time as updating bug fixes to an addin? On the application software we develop here where I work, we tirelessly take the user's perspective when deciding what kind of prompts, keystrokes and mouse clicks to require of the user and minimize them to the best of our abilities to avoid having to have the user enter anything at all (as do you as well, I am sure). Dialogs and things that force the user to have to "think" are a bane to us as designers. We donG??t like them and believe our users donG??t either. I think it is a universal concept and why Microsoft developed the ClickOnce install paradigm right? The more dialogs we throw up in the users face the poorer his user experience and the more difficult we view our software to use. This is especially true of superfluous dialogs asking me whether or not I want to change something I that I would normally never want to change. There is often a tradeoff of usability versus flexibility to consider, but when something is the minority case (especially the vast minority case), then it is usually a simple call to ax it and hide its selection away under some more advanced menu or settings page where only users that truly need it will know what it means of even care what it means. Take MS Word for example. Go look at some of the settings. Imagine having to answer the prompts for those options on updates or installs. The approach is to keep it out of the face of people that wouldnG??t normally use it or at least out of the context in which it makes no sense.
Sure, maybe if you have one million users, and once every 10th update install, one of these users just might happen to need to change keystrokes for some unknown reason, he or she might finally choose the G?YESG? option for the right reason. If people are hitting YES now, I am confident it is only because they are confused when being confronted with a decision they donG??t truly understand and are simply afraid something will break if they donG??t, not because they understand why it is prompting them and YES is the most logical choice in this case especially since it is on the left of the YesNo buttons (and the default button too, right?). Since changing keystrokes and creating new toolbars is counter-intuitive for a maintenance install, the confusion might be that if I donG??t choose G?YESG?, I might loose access to some previously existing function so I better say G?YESG? just in case. I have been updating VA for years now and have always disliked seeing the G?Big Three PromptsG? make their appearance, in which they are asking me questions that I could never confidently answer unless I completely understood the implementation/integration of the VA and VS. But since most of your users (like me) really do like VA and what it brings, such annoyances fall under the category of just ignoring warts on a pretty girlsG?? face. But, from a philosophical standpoint, would a short trip to the cosmetologist, to get those warts burned off, really hurt her? It wonG??t make her more loved but it will keep people from wincing the first time they see her.
VA users are probably pretty techno-savvy and as a result donG??t fall apart when confronted with confusing dialogs. They simply answer them with their best guess and assume that if their guess was the wrong one, they can figure out how to reconcile it later. But that doesnG??t mean they like guessing or even being asked since there is only one right answer and it rarely varies. Enough said.
|
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Jun 16 2005 : 12:06:40 PM
|
rittjc, I don't think you read support's message properly. They did a simple experiment which showed that "no means no" when they test it. Did you try their experiment?
Yes is sometimes necessary when something has changed in VA. Then there is a genuine conflict between getting the new stuff and trashing all your settings. However, I do wish VA knew whether anything had changed between your current installed version and the version you're about to install, and didn't ask you if there were no changes. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 16 2005 : 1:24:06 PM
|
Stephen, sorry buddy but I don't think you read support's message properly. They did a simple experiment that showed "yes means yes" when they tested it.
That had nothing to do with my problem and I am not even sure why they did it that way unless they misunderstood what the problem was that I was having (as I stated in my response). My problem was, and still is, when you hit NO it acts like you hit YES, not when you hit YES it acts like you hit YES. I, personally, could not care less if hitting YES to a prompt asking about changing key bindings, actually changes key bindings, since, in my long dissertation, I indicated that no one would want to do that under normal circumstances. I didn't want the bindings touched, period. Updates should be innocuous and non-intrusive. This was why I hit NO when I was prompted if the install should modify them.
BTW: Stephen, you hit the nail on the head in your response, and I think if you reread you will concur with my view (as I would expect most to in this case). I do agree that if a new function was added or unavoidably changed that mandates a key binding or toolbar change, that then the user could be prompted with this choice. But that is the anomalous case and very rare I would think. As a result of the rarity, I would prefer just a notification and I could go add a bind if I need the new functionality they might have added.
This may seem like a bit of an overblown gripe, but you have to admit that one thing we all like about VA and WholeTomato is their responsiveness to customer requests. That's why we spend time on a discussion forum debating functionality and problems. Who else other than MS would we take the time to do that with? They are an example to all of how unusual support breeds unusual loyalty. Someone competing with them has to do more than just compete on features and price, they have to deal with a competitor that has fierce loyalty as well. |
Edited by - rittjc on Jun 16 2005 1:39:06 PM |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Jun 16 2005 : 1:58:02 PM
|
quote:
Originally posted by support
We exit VS2005 and resinstall 1413. We answer "no" to the rebuild/reset prompts.
We start VS2005. F7 still opens the dialog we expect. It's still assigned to File.OpenFile.
|
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 16 2005 : 5:04:10 PM
|
rittjc i have also done the same test as Support describes. for me No means No and Yes means Yes. the buttons DO what they say. tested using win2k pro, VS 2005 beta 2 and VA 1413.
philosophically i agree with you about the question, and Stephen's point about VA working out for its self what is going on is very attractive. however reality can be messy, and reliably detecting things isn't always easy. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 16 2005 : 5:42:06 PM
|
Well, if it is Visual Studio trashing custom key bindings because of registration changes of the new, then at least that part of my points are moot. Assuming it is and assuming they fix it in the RTM then this is a non-issue as far as VA/WT are concerned. The other issue of not having to answer the change prompts is ancillary to my original post. I am betting that the post by Wannabe is more enlightening in that it is a VS problem rather than a VA problem. But I can say without reservation that it is "still" a problem in VS 2005 latest beta (2).
OTOH, the trashing of bindings may be related to how you are reregistering the updates. There are some "CommandPreload" registry entries that have value meanings to direct VS to recognize changes to the addins as though this is a state variable of some sort. I am assuming that WT is using these somehow to direct changes. It could be that they have to be used in a certain way maybe even one that is not well defined by Microsoft or should not be used at all in the case of updating (since the changes are incremental) and the way or the fact that VA is using them will result in some unintended consequence of resetting of settings in the VS environment. Of course that is speculation and I will defer that to the experts at WT but it is something to consider. In short, it may not be a bug in VS but rather a obscure/unpublished requirement of Addins during registration/reregistration that makes the updates benign and if you don't do it that way it considers the update to be a major change like a new installation and causes the unintended trashing of the key bindings.
That's my thought on it, though I'm a bit out of my league here... |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 16 2005 : 5:47:10 PM
|
quote:
Originally posted by Stephen
quote:
Originally posted by support
We exit VS2005 and resinstall 1413. We answer "no" to the rebuild/reset prompts.
We start VS2005. F7 still opens the dialog we expect. It's still assigned to File.OpenFile.
Stephen, I stand corrected. I did misread support's reply. The answer to support's reply that is yes, it does indeed act different. I am using C# and I think that I have this compile setting tied to that context of the text editor for C# rather than globally, though I don't know if that makes a difference. It may because I definitely get different behavior and it is repeatable. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 17 2005 : 3:12:25 PM
|
rittjc i have a win2k pro test system with vs2005 beta 2 + VA 1213 installed. i have assigned the keyboard shortcut CTRL+SHIFT+F7 (in the text editor) to the action Build.Compile
i then re-install 1413, answering NO when asked if i want to reset the IDE i then open the IDE and this keyboard binding is still there.
can you post the steps you are taking? perhaps there is some specific condition that has to be met for this problem to show up. when i test it the problem does not show up. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 17 2005 : 6:17:21 PM
|
My settings are that I have bound F7 "Globally" and assigned it to Build.BuildSolution. If I install and choose NO on all three, I get my key mappings reset. Also I noticed that there is a font color that that hides certain selections that I have overridden (text color = background color = shows a hidden selection). I don't remember which selection in the Fonts and Color that this one is (I had overridden it before so it contrasts) but it does get reset as well during an update so it's not just key bindings that are taking a hit by the NO-A-THON on the update (sorry for the euphemism, I just couldn't resist  ). I verified this also happens with a coworker using 1413 as well.
XP SP2, VS 2005 Version 8.0.50215.44
I have to admit is is surpizing to me that you are having trouble reproducing it. It has been pretty easy for me to do and this has been the case since the first VS beta that had the VS 2005 support.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 19 2005 : 2:27:00 PM
|
right, time to get serious about pinning down what is going on here.
test 1:
boot OS - win2k pro SP4
load vc2005 beta 2 with VA 1413 installed - 8.0.50215.44
without loading any projects open tools -> options keyboard
assign F7 globally to Build.BuildSolution, replacing the existing key binding
quit the IDE and reload the IDE, still not loading any projects, to check that this key binding is stable - it is
quit the IDE and install VA 1413
i only get ONE question box, where i answer No
load the IDE, still not loading a project, and check the key bindings, F7 is still bound globally to Build.BuildSolution
so test 1 failed to recreate your problem. obvious differences:
the OS is different, i don't have a winXP pro VMWare machine setup, so i would like to avoid having to do so.
you got three question boxes, i only got one. what other IDE's do you have installed on this machine? i am doing this text on a machine with only 1 IDE installed, vc2005 beta 2.
test 2:
boot OS - win2k pro SP4
this machine has VC6, vs2003 and vs2005 beta 2 all installed on it.
load vc2005 beta 2 with VA 1409 installed - 8.0.50215.44
this will allow me to test the upgrade from 1409 to 1413
without loading any projects open tools -> options keyboard
assign F7 globally to Build.BuildSolution, replacing the existing key binding
quit the IDE and reload the IDE, still not loading any projects, to check that this key binding is stable - it is
quit the IDE and install VA 1413
message box 1 = "do you want a new toolbar for visual assist X in Microsoft visual C++? ..."
answer No
message box 2 = "the installer is about to reset to default state all menus, toolbars and key bindings in Microsoft visual studio .net. ..."
answer No
there was no message box 3, presumably because no autotext files on this test system have ever been modified. i only use this for testing, not developing.
load vc2003 by mistake *oops* then quit it without loading any projects
load vc2005 beta 2 and check keyboard bindings, F7 has been reset.
reassign F7 in vc2005 beta 2 and quit the IDE
load the IDE to make sure this has taken - it has
install VA 1413 over the top of its self, answering No to all dialogs
this time i got a 3rd message box:
message box 3 = "the installer is about to reset to default state all menus, toolbars and key bindings in Microsoft visual studio 2005. ..."
answer No
load the vs2005 beta 2 to check the key bindings, and F7 is still bound to Build.BuildSolution.
the first keyboard reset when upgrading from 1409 to 1413 is a known bug which does not effect 1413 and above.
as a final check i reinstall 1413 over its self again
i answer No to the 3 message boxes as listed above
load the vs2005 beta 2 to check the key bindings, and F7 is still bound to Build.BuildSolution.
rittjc i presume you can agree that all of this constitutes a good test. further i presume you will also agree that there must be some difference about your system that i am not reproducing.
what is this difference? what are you doing that i am not? what message boxes are you getting? what IDE's and plugin's do you have installed? are you logged in with sufficient permissions? grasping at straws on this one. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 19 2005 : 11:18:47 PM
|
feline,
I am not sure what is different. Since then, I installed 1414. I noticed that four prompts must be NO'ed after updating (did they add one?). When finished, at least one binding has been reset. I am only aware of the Global:F7-Build.Solution, though I may have other key bindings overridden and trashed, I have them saved to a private profile file to reload. After installation, have to re-import the settings because F7 produces default behavior.
I am sure you are doing exactly what you say you are doing. I don't have an idea why you see a difference. It happens on my machine at home as well. The only difference that jumps out at me are I am using XP SP2 (both at home and work). Other than that your tests seem legit.
The only thing I can do is assume it has something to do with VS as one poster suggested. This could certainly account for differences we see because there is no guarantee that our VS installations are anywhere near similar. Because they have the same version number means nothing to anyone who has worked with the VS 2005 beta fiascos of recent experiences. I am sure MS has put you folks in a bind quite a few times since the VS 6 days. What's one more? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 20 2005 : 2:30:47 PM
|
theory A - this is an OS specific problem
theory B - there is something about your configuration that is critical for this.
i have seen B happen before with colours getting upset on a VA upgrade. can you post a zip file of your saved out profile? i will then see if it loads OK on my test machine and re-try the test. if you don't have anywhere to easily host it if you email me via the forum i will reply, so you will get my email address.
i don't post my email since i don't need any more spam 
oh yes, do you have any other plugin's installed?
what are the 4 message boxes that you are getting? which other IDE's do you have installed on these machines? or do you have a different combination of IDE's on the two machines? |
zen is the art of being at one with the two'ness |
Edited by - feline on Jun 20 2005 2:32:20 PM |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 22 2005 : 09:12:25 AM
|
feline, I will be glad to email you internally to get an address to send you my profile.
I just installed 1416, and it appears the NO prompts have been reduced to 3 again! Woohoo! I counted 4 on 1414 (that's the current record for the number of times a user must repeatedly answer that he or she is the kind of user who considers his current settings sacred). It may not have been this machine that I got the 4 prompts on (NO prompt counting has become a hobby of mine, "can't beat em' join em'", I always say) .
It seems that VA updates need you to confirm you don't want your settings touched (as though there was a reason you would want them reset...still waiting for someone to explain the rationale for wanting ones settings reset by an addin update...any takers?) for every instance of VS on your machine. Maybe you could put a checkbox that says: "I'm a masaquist, please destroy any of my settings you can find, please". If the user checks this checkbox, then VA could issue itself an extreme prejudice order and go on a hunt like a CIA Spook and assassinate every "key binding leader" of sovereign VS installations. Sorry for the cheesy metaphor, the levity helps me deal with the irony.
You probably only have on instance on your machine so you only see one "No me or else" prompt asking if VA should destroy the favorite settings that took you so long to accumulate and are so precious to you. Even though, again as I have so "eloquently"  stated, I couldn't imagine why someone would ever want this done following an update to VA, at least there is a prompt (though NO doesn't work in my case).
By the way, I have captured the screen shots of these NO-me-or-else prompts. I will be glad to include them in the attachment when you send me your address to post my suspect profile to.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 22 2005 : 2:55:21 PM
|
you know, i sometimes get the impression that you don't want VA to make your settings more consistent, for ease of remembering the keyboard shortcuts
as for why does VA want to do this? now and then VA requires a reset to correctly register its self, due to "design issues" in the IDE. this is why when support post a new build notification they say whether or not a reset is required. still, i will email support and ask about a "i am a masochist" check box
i have received and replied to your email, hopefully this will get us somewhere. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 22 2005 : 3:30:26 PM
|
Good deal feline.
As far as wanting VA to make my settings "more consistent", why is it assumed that the settings are ever "less consistent" to begin with? Less consistent with whom? From a philosophical standpoint, consistent with what it was before is the only consistency that users recognize or care about. This is true of updates not necessarily initial or first time installations.
I understand occasionally you add more commands, and they have alternate key assignments that the user might want to be made aware of them and that they might possibly conflict with the userG??s settings, but the fact is that we are creatures of intense habit. No feature you could come up with, no matter how useful would make me want to "relearn" the compile key being F7 just to have this feature assigned there. From WT's standpoint, key assignments may be arbitrary, but to a user set in his or her way, they are sacred. Consider it G?Rain-man needing to watch Judge Wapner at 7G? if you will, but most people do not like patterns changed at all. Reassigning someoneG??s editor keys is akin to trying to "rename" their kids. Even if they have given their kids stupid names like G?ThorndikeG? or G?HerbertG? (sorry if there are any ThorndikeG??s or HerbertG??s out there that would take offense at this), but you just don't intrude in that domain even for the sake of sanity. 
The feeling (at least from me) where something tries to reassign my keys is like a hostile attack on my configuration where someone is trying to force their will on me (a sort of a Visual Studio Fascism if you will). I feel like I am in battle of wills with the installer to see who wins. Will I be forced to use new key assignments I donG??t want to or not? So far the installer has been winning. 
I'll get you the file you requested. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 23 2005 : 4:55:40 PM
|
bottom line, as far as i am concerned, VA should never reset the keys when you say no.
"constancy" was consistent with the default settings, since if we take this to seriously it is going to drive us nuts. i know this is driving me up the wall, and i am not even getting this problem.
using a win2k pro VMWare machine with VC6, vs2003 and vs2005 beta 2 installed, with VA 1416 installed i imported your settings into vs2005.
this produced the two following errors:
Error 1: Projects and Solutions: Unable to import property 'ProjectItemTemplatesLocation' because it contains invalid data '%vsspv_visualstudio_dir%\\itemtemplates'.
Error 2: Projects and Solutions: Unable to import property 'ProjectTemplatesLocation' because it contains invalid data '%vsspv_visualstudio_dir%\\itemtemplates'.
this could be due to the fact that i have installed vs2005 to D: drive, since C: ran out of space.
following the import i have a new screen layout, and Build.Compile is assigned to F7 (Global)
i tried closing and re-loading the vs2005 IDE to make sure this was stable, and it was.
then i installed 1416 over the top of 1416, answering NO to each of the questions along the way. load the IDE, the screen layout is the same, and F7 is still assigned to Build.Compile
for the moment i am assuming this is not an OS specific problem. no one else seems to be having this problem, so what are you not telling me?
from the screen shots you sent along you have VC6, vs2003 and vs2005 beta 2 all installed on the same machine. is this correct?
you speak as someone who has knowledge of and experience in writing plugin's for the IDE. so it seems reasonable that you have plugin's / extensions installed on your system. what are they and where can i get copies of them?
my only working theory is that there is something about your machine that is causing this problem. do you have VMWare or Virtual Machine available? do you have any other test machines you use with compilers installed on them? |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 23 2005 : 6:02:09 PM
|
*um* how heavily have you re-mapped the keyboard? while trying to test something else i have just discovered that the cursor keys no longer move the caret around inside the editor in vs 2005 beta 2.
this seemed to break after i imported your settings. resetting vs2005 has fixed the cursor keys. most strange. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 24 2005 : 08:54:43 AM
|
| Agreed, most strange. It doesn't do that for me. Everything seems to work fine. Do you think this is a localized problem? |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 24 2005 : 1:19:43 PM
|
I have toyed around and created Addins for a while but I currently don't have any installed on this machine other than VA.
I do have VS6, VS2003, and VS2005 all on the same machine. I have apps developed and maintained in all three. It would be safe to assume that users who don't want their settings touched in one, wouldn't want their settings touched on all three. We may disagree on the philosophy of updating/settings changes but whatever a person's stand on the issue, I can't see it being different for each release of VS installed on their machine.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 24 2005 : 2:53:37 PM
|
i am running out of ideas *sigh*
do you have a second machine that you do development work on? do you work with anyone else who has the IDE installed? i am wondering what happens if you import your settings onto a different machine.
are you using a localised IDE, OS, or keyboard? this could explain the strange keyboard effect i saw if so.
the only sensible test left i can see to try is to un-install VA, rename its directory (to stop windows re-writing over the same bit of hard drive), delete references to VA from the registry, re-set the IDE and then install VA.
i believe the first install of VA does a reset automatically on all IDE's, since it requires this in order to properly register its self. not a nice fact, but somewhat unavoidable.
if upgrading after this still resets your IDE i don't know what to suggest short of reinstalling most of your programs, which is not a good answer. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jun 25 2005 : 7:00:42 PM
|
rittjc made a commend, "I am sure MS has put you folks in a bind quite a few times since the VS 6 days."
We started in the VC 5.0 days, prior to the MS version coined, "Intellisense." [:;]
MS documentation and APIs require add-in that use VSIP to reset the IDE on every install, even for updates. The process resets a lot of internal IDE structures and settings that get whacked easily. (VS2005 still has the requirement but offers an API to save/restore settings.)
We hacked around the requirement for the reset and display prompts instead. Now that there are so many IDEs, you get a lot of prompts.
We could reduce our prompting to one big, "Yes or No" that applies to all IDEs but we'll likely get a request for the way it is now. Perhaps we add a checkbox to "Apply to all IDEs."
case=686
As for the problem with key bindings... We strongly suspect something in your environment causes the IDE to reset despite our effort not to make it happen. (We remember one add-in that caused a reset when another add-in was installed.)
We understand you have no other add-ins installed. That eliminates the obvious.
Assuming the problem is localized to VS.NET, you might install that IDE if you even get time. We know this isn't ideal but it's our best suggetion.
As for getting three *or* four prompts, you get one extra if VA X detects custom changes to your Autotext and Code Templates. |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jun 27 2005 : 1:18:53 PM
|
Well, if you believe this is a local problem, I am inclined to believe you. I am intending to upgrade to a 64 bit machine and I will take my VS settings and see if the problem disappears. I would but nothing past Microsoft. You have to remember, I am a staunch MS supporter so for criticism to be coming from me means they have gone way beyond what is just unreasonable.
The extremely poor code and support for uninstalling betas is completely inexcusable and has caused great consternation for just about everybody that has used it.
Thanks for your support. I will report my results back when I get a chance. In the mean time you should probably assume this is an anecdotal problem and not waste any more time on trying to figure it out. If it was your problem, you would probably have found it already.
|
|
|
| |
Topic |
|
Topic Locked
