| Author |
 Topic  |
|
|
rittjc
Ketchup Master
USA
84 Posts |
 Posted - Jul 05 2006 : 11:41:40 PM
|
When running, you cannot use ListMethods in Visual Assist because it appears to the debugger that calling up that list is causing an edit. This is the same behavior as if you simply try to edit code in the debug mode while running.
You get the following message:
"Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled. The option can be enabled in Tools, Options, Debugging."
What is VAX doing that makes VS 2005 think it is trying to edit? I am simply using it for navigation to a specific function. Are you aware of this problem? |
Edited by - rittjc on Jul 05 2006 11:42:40 PM |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jul 06 2006 : 12:21:50 AM
|
We were not aware of the problem.
What build of VA X do you have? |
 |
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jul 06 2006 : 10:48:53 AM
|
VAX 1524
This should be easy to reproduce. Simply run a program in VS 2005, try typing on a page to make sure you are set up properly to get that message. Then try pulling down the List Methods combo list and something VAX is do makes VS 2005 thinks you are trying to edit something. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 06 2006 : 6:17:20 PM
|
are you working in this C# ? if so then this rings a bell.
can you look at the tabs, do they have small blue padlocks on them, to indicate that the code is read only?
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4711 |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jul 10 2006 : 12:20:01 AM
|
Yes I am using C# and I am on a 64 bit machine. I assume that 1243 means some RQ number or something, but since I don't have a clue how to look up the status of that can you tell us what that status is? In debugging you want to browse to a method as well as in edit so it is also important to be able to do this.
Thanks |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 10 2006 : 6:21:13 PM
|
case=1243
yes, this is the number of the case in our bug tracking system. for now the work around is to use the mouse on the list. one of the developers has looked into this, but the basic problem is that the IDE is trapping the keyboard before VA, so it is showing the message box before VA has a chance to do anything about it.
as have to sneak in around behind the IDE, since it does not know we are here, and sometimes this does not work so well *sigh*
we are hoping to find a better solution, but i am not sure when that will happen. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Jul 31 2006 : 9:29:29 PM
|
This this on a path to being fixed or is it thrown into a category of "nice to do but not neccessary"? It is a very annoying problem. I just VA quite a bit when debugging but now have to stop debugging or break to browse (or find if I can remember the routine name). It is in effect, that VA functionality is disabled during debug..
Your work around does not work. I suspect it has to do with the speed of the processor. If users have a slow enough processor then they might not see it when clicking on it. I suspect it is some kind of race problem. Clicking on the combo STILL causes it to happen, every time on my machine. If it were a minor annoyance or if there was a workaround, then it wouldn't be so bad, but as it is it is quite a distraction.
I afraid you will think it is not important, but before too long, most developers will be running 64 bit machines.
What do you think?
Jim |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Jul 31 2006 : 11:15:18 PM
|
It turns out that it does not have anything to do with 64-bit processors or speed or anything. It is directly related to the fact that VS doesn't know we are doing so much with the window.
It is not being ignored, it is just quite a bit harder problem to resolve than it at first appears. |
Joe Pizzi |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Aug 17 2006 : 12:23:51 AM
|
Can anyone explain why this problem suddenly "started happening" when it used to work in previous releases with Visual Studio 2005 of which I have never changed? It seems as if it is thought to be a Microsoft problem of not recognizing you. If there is validity to that explanation, then why did they "stop recognzining" you since it this problem happened by chaning out versions of VA?
I am not being a smarta**, I just get frustrated in debugging these days and feel like VA has become entirely useless in this most critical area where it used to carry the mail. The number one thing you do in debug is browse to code to set breakpoints. Now you have to check the "you can't do that boxes" that come from trying to list functions that you use in the edit mode. This is the most significant thing that has happened to VA since I started using it about 10 years ago. It has become of marginal utility. I'm sorry, I don't know any other way to put it. |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Aug 17 2006 : 01:38:40 AM
|
Well, according to the information in the case, the problem only occurs if you use the alt-m hotkey to open the list. If you use the mouse, it does not happen.
Since there is a workaround (using the mouse), the priority has been lowered on resolving the issue.
Is it possible that this stopped working when you started using the hotkey (I am assuming that the case information is accurate for you, too)? If not, I can't explain why it previously worked.
This case was opened a month before you started this thread, so it is possible that you are actually experiencing a different problem and we incorrectly identified it as the same as this case. |
Joe Pizzi |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Aug 17 2006 : 03:32:21 AM
|
This behavior was first reported in August 2005:
http://forum.wholetomato.com/forum/topic.asp?ARCHIVE=true&TOPIC_ID=3858
So any recent change in behavior you are experiencing is unlikely to have been caused by a VA update unless you were using a build from well before August 2005. Had you modified the Edit & Continue option in the IDE options dlg around the time this started happening?
There should be an improvement in builds 1525 and later in that alt+m will open the list without the dlg appearing (likewise with using the mouse to open the dropdown). However, unless you disable Edit and Continue, typing in the edit field to filter the list will cause the dlg to appear and the list to close. Are you still using build 1524?
|
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Aug 17 2006 : 10:13:42 AM
|
jpizzi, sean,
If you had read all of my posts in this thread you would see it has nothing to do with keys our mouse. Others have since confirmed the same. It has to do with machine speed. This is why it was originally thought to be a 64 bit machine problem, but turned out to be simply faster generation machines which will soon be ubiquitous. In other words, there will not be just a small handful of people affected but a progressively growing crowd. If people update their machines, on average, about every 4-5 years that means about half will have the problem within two to two and a half years from when it first appeared right? I mean you are not dealing with the average joes/joelines that get their computers from the special at Best Buy, most people of your customers will upgrade to substantially faster machines.
A more substantive question would be what does Microsoft say it is? Surely WT has contacted Microsoft concerning this reproducible problem, who could give a definitive answer as to what is happening and who to resolve or work around it from the WT side. Something about popping up the list convinces Visual Studio that an edit is taking place. And since it is a "timing" specific problem they could certainly explain how to work around it or what is being done incorrectly in sequence where the offending request should be delayed before invocation, until it fixes the race condition or whatever it is, regardless of machine speed. If it were a logic problem then it would be unfixable without a change in VS. As it is, it has nothing to do with the logic functions but the timing as evidenced by people only seeing it with faster machines or it disappearing for a some when invoked with less overhead consuming events like a mouse click.
Like I said, I am sincerely not trying to be a jerk. I am afraid (a fear which is seemingly validated by the response suggestions of a workaround that does not exist for everybody and fewer and fewer as machines get faster and faster) that because it is believed that there is a workaround with a mouse, that the problem has tabled. It would not be an unreasonable stance for WT to take, if it were true, but it is not. I am also concerned that WT views it as a minor annoyance and that view sort of compounds a natural ambivalence toward it. Believe it or not, I take no pleasure whatsoever in bitching about this or any other problem.
|
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Aug 17 2006 : 10:15:49 AM
|
sean,
To answer your question, yes, I am using 1524. I will update to 1525 and let you know if it makes a difference. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 17 2006 : 8:00:12 PM
|
rittjc the following is simply my understanding of the facts.
this problem has nothing to do with machine speed, i am seeing it inside a VMWare machine. while my host PC is nice and powerful, inside a VMWare is not normally a blisteringly fast environment.
this problem seems to be keyed to the blue padlock on the tab. if this is there and you try to type in the code window then the IDE will popup this dialog. the IDE thinks that you are trying to edit the code when you are in fact using the alt-m list.
this problem is not specific to VA, have a look at this page http://www.viemu.com/viemu_doc.html and search for Prevent VS2005 warning "cannot edit while running"
this plugin, to emulate VIM inside the IDE, wants to pick up the letters h, j, k, l as movement commands, which again the IDE will see as you trying to edit the code. in this plugin the solution is to change the source code back to being editable, even though the IDE thinks it should be read only. personally i wonder if this solution is going to cause different problems further down the line.
if the IDE can be convinced not to make the source files read only then the problem should go away. i don't really do any development in C#, so i am not really familiar with the relevant IDE options. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Aug 17 2006 : 10:21:54 PM
|
quote:
Originally posted by feline
rittjc the following is simply my understanding of the facts.
this problem has nothing to do with machine speed, i am seeing it inside a VMWare machine. while my host PC is nice and powerful, inside a VMWare is not normally a blisteringly fast environment.
Well, the condition of a speed problem has nothing to do with machine speed in and of itself, but rather the "relative" speed of doing two separate or dependant tasks. This can be affected by the size of processor cache, disk cache and which thread or task is using what. So as far as VMWare, it might even have a more exacerbated race problem as VMWare simply emulates the machine. So say, for instance, that your processor is so much faster than your IO and there is code that requires a write to a disk to happen faster than its write can be registered then you get a race condition. This can be true if the machine runs at 1 Hz if the IO/Processor ratio is such that the code needs a spinlock or something like that to prevent overlap. It has nothing to do with absolute speed. But like I said, new machines with newer technology exploit caches and have differing performance criticalities and bugs can start to appear then, bugs you have no idea could even exist.
quote:
this problem seems to be keyed to the blue padlock on the tab. if this is there and you try to type in the code window then the IDE will popup this dialog. the IDE thinks that you are trying to edit the code when you are in fact using the alt-m list.
this problem is not specific to VA, have a look at this page http://www.viemu.com/viemu_doc.html and search for Prevent VS2005 warning "cannot edit while running"
this plugin, to emulate VIM inside the IDE, wants to pick up the letters h, j, k, l as movement commands, which again the IDE will see as you trying to edit the code. in this plugin the solution is to change the source code back to being editable, even though the IDE thinks it should be read only. personally i wonder if this solution is going to cause different problems further down the line.
if the IDE can be convinced not to make the source files read only then the problem should go away. i don't really do any development in C#, so i am not really familiar with the relevant IDE options.
I keep seeing the blue padlock mentioned here and don't know what the deal is. I think the blue padlock means that the buffer is write protected which would happen whether they drew an indication that the buffer is locked or just simply locked it and let you figure it out on your own. The net affect is the same.
But, I am not sure how to address the claims that it is probably MS because others have similar complaints, especially since you folks have fixed it in version 1532 as Sean suggested up above. You will also see my post with much rejoicing from earlier Thursday. I had confirmed it on my dual 32 bit processors at work and now on my 64 bit processor at home. I have not seen it on either machine since I have installed this. My ratio was about 99% of the time I saw it on both machines using 1524. This includes using it with "Edit and Continue".
Incidentally, this may be inconsequential now, but the claim that it didnG??t happen with a mouse or using Alt M, or whatever is a disproved myth. On both of my machines, I had no trouble consistently reproducing it (99%) with either machine, at any time. I even created macros to invoke the command and added a button on the main tool bar to completely disprove any association with the editor input at all by the fact I completely bypassed it by invoking it from a main tool bar click that fired off an event, which fired off a macro to the vassist command server. So it never came in as an event via the editor, it came from the appG??s frame straight to the macro server to the vassist server. So, the editor, and its blue G?buffer lockedG? indicator are not even involved with that command path. But the fact that some could circumvent the problem by using keyboard or mouse, suggests to me that it is (was) very much a timing issue because both would certainly execute the same code from the event handlers on.
So now I am happy. I consider this one resolved. You may have fixed it by accident, but me, I could care less as long as it never comes back. I will take an accidental fix, a hack, a patch, a rewrite, or whatever it takes, any day over empathy.
Jim
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 19 2006 : 10:32:19 AM
|
if it is fixed then that is good, and i am happy.
if my understanding of what is going on here, and the trigger, is so wrong then that is a slight concern, but not something i am going to worry about if the problem has gone away. |
zen is the art of being at one with the two'ness |
|
|
|
rittjc
Ketchup Master
USA
84 Posts |
Posted - Aug 21 2006 : 01:02:42 AM
|
| I think that would be my approach as well. Don't fix a problem if you don't know there is one. I agree the explanation is bothering but I am very results oriented myself. |
|
|
| |
Topic |
|
ListMethods not working in debug
