Problem with <enter> key in VS 2010

[dboggs]

I sometimes experience an extremely irritating/dangerous problem using VS 2010 w/ Fortran 12.1:

Under certain conditions (which I'm having trouble defining), the result of the key becomes disassociated with the cursor location; i.e., the intended new blank line gets inserted not at the cursor but instead at some other place in the file! All other keys work correctly, e.g. I can insert a new letter at the cursor, but a new line shows up somewhere else!

Sometimes this condition seems to occur during, or after, editing in split-screen mode. It alsohappens when running in debug mode after a run-time error. Depending on the RTE, an instant break point may be automatically inserted at the offending line with the cursor positioned there. But the editing window shows a double image, apparently with two different views of the code superimposed but not exactly registered. I suppose that one of the images corresponds to the one showing before the RTE, while the other view is the one showing the break point. I'm guessing that the current cursor location is somewhow tied to both of these images, that is, two different spots in the code. The display can be cleared up by rewriting it. But, editing acts as though most keys behave according to one of the cursor locations, and the key behaves according to the other location.

Or something like that.

I can only restore things to normal by exiting VS and restarting.

Has anyone else experienced this bizarre behavior?

[krishnabc]

I have also experienced this bizarre behaviour usually when editing in split-screen mode.

[dboggs]

This problem still remains after installing Update 8 (and note that the thread title should read "Problem with key", but the <> around "enter" apparently caused the whole word to be lost in the original post).

The best way to consistently see this problem is to edit something insplit-screen mode. Then locate the cursor somewhere in the top screen, say, and press . Well, there is a new line created SOMEWHERE but not where the cursor is!

This problem is deadly serious. The key action dinks up some line somewhere in the code and there is no way to find it. Nor can it be recovered using Undo. The code is damaged! The only way I know to repair it is to hope that the compiler will find and report the error, but in one case it wasn't found until runtime, and only then because an obscure input parameter caused execution to take a path that just happened to have the dinked line!

This is so serious, I have to force myself to avoid the temptation to split the screen--out of fear I will press , and then it's too late. I must just pretend like the split-screen editing feature simply doesn't exist.

[Steven_L_Intel1]

Is this the same problem as described here? If so, it is fixed for a future release.

[dboggs]

Yes, it sounds like the same problem. I'm surprised that when I reported it earlier, I got no response (except from one other user who simply said he also experienced it).

There does seem to be some discrepancy over how long this problem has existed. I used VS2008 before, and had no problem. It came with VS2010.

I can't emphasize enough how serious a problem this is. It makes split-screen editing EXTREMELY dangerous--it's as simple as that. THE EDITOR (whichever one it is that is known to have the problem) SHOULD HAVE BEEN RECALLED! I'm amazed that it was discovered/report in update 7 (or before), and it was not fixed in update 8. I will force myself to avoid split-screen editing until it is fixed. How many updates will I have to wait?

And fyi, I have also experienced the same problem after a run-time error--along with the funny non-registered split-screen image that I described in my original post. I hope that the problems are related and both are fixed at once.

[Steven_L_Intel1]

I will ask the developers if they can get the fix in sooner. Stay tuned.

[IanH]

As a workaround - rather than using split screen editing consider having multiple windows (that point to the same file) open (i.e. Window > New Window) and then dock them as it suits. This is how I've worked for some years now (I prefer the full fledged window to the split view) and I have not experienced any problems with the new integration.

You can't dock both vertically and horizontally (if you have sufficient single screen real estate to bother with that), but you can float things to your hearts content - which is useful for multiple monitor setups.

[dboggs]

Thanks for this tip Ian. It's not very obvious how to manipulate this feature, but after getting used to it I like it.

This is much better than just waiting for Intel to fix the broken split window!

[Steven_L_Intel1]

The developers have told me that their fix will be in Update 9.