How Hard Can It BE??? (VS2010 mini-rant)
-
Look, I know VS2010 is a complex piece of software, and I don't expect it to be perfect. I can't quite forgive the failure to refresh the screen at times - but I can put that down to my machine at work, as it rarely if ever happens at home. But why oh why oh why when I set a breakpoint in debug, and it hits the breakpoint, does it fail to display the line it's actually broken on ?? It usually comes pretty close - within one or two lines - but I don't want to have to scroll to see where it's stopped! It does the same, occasionally, with Find - positions the cursor on the word that it's found - but doesn't scroll the window to show the line. - This happens so frequently that I find myself doing the Left-Right cursor key waggle to get the line to show almost automatically after a Find or debug break. It's so blatantly fundamentally broken!
___________________________________________ .\\axxx (That's an 'M')
-
Look, I know VS2010 is a complex piece of software, and I don't expect it to be perfect. I can't quite forgive the failure to refresh the screen at times - but I can put that down to my machine at work, as it rarely if ever happens at home. But why oh why oh why when I set a breakpoint in debug, and it hits the breakpoint, does it fail to display the line it's actually broken on ?? It usually comes pretty close - within one or two lines - but I don't want to have to scroll to see where it's stopped! It does the same, occasionally, with Find - positions the cursor on the word that it's found - but doesn't scroll the window to show the line. - This happens so frequently that I find myself doing the Left-Right cursor key waggle to get the line to show almost automatically after a Find or debug break. It's so blatantly fundamentally broken!
___________________________________________ .\\axxx (That's an 'M')
When the debugger is one the wrong line, it might be inconsistent endline or complex macros (C++ only). Otherwise, it might be related to your setup (variable height used by toolbars, lot of very long lines, in your code, zoom not at 100%, code windows too small... that might affect the result). Find windows if not docked (and particulary if big) will sometime be over searched text. Most of the time, I close the windows at first hit and then uses F3 to search other hits.
Philippe Mori
-
When the debugger is one the wrong line, it might be inconsistent endline or complex macros (C++ only). Otherwise, it might be related to your setup (variable height used by toolbars, lot of very long lines, in your code, zoom not at 100%, code windows too small... that might affect the result). Find windows if not docked (and particulary if big) will sometime be over searched text. Most of the time, I close the windows at first hit and then uses F3 to search other hits.
Philippe Mori
Philippe Mori wrote:
When the debugger is one the wrong line, it might be inconsistent endline or complex macros (C++ only).
Nah - just plain old C# - it isn't that the debugger is on the wrong ine - its that the line the debugger is on isn't visible in the code window without scrolling to it.
Philippe Mori wrote:
Otherwise, it might be related to your setup (variable height used by toolbars, lot of very long lines, in your code, zoom not at 100%, code windows too small... that might affect the result).
It could be one of those - although my set up is as close to out-the-box standard as I can imagine - but even if it is, surely it 'knows' which line needs to be shown, and should be able to ensure it is visible!
Philippe Mori wrote:
Find windows if not docked (and particulary if big) will sometime be over searched text.
Not in this case - my find window is on another screen. Again, it's simply a case of the source window not scrolling completely to show the line on which the text cursor is sitting.
___________________________________________ .\\axxx (That's an 'M')
-
Philippe Mori wrote:
When the debugger is one the wrong line, it might be inconsistent endline or complex macros (C++ only).
Nah - just plain old C# - it isn't that the debugger is on the wrong ine - its that the line the debugger is on isn't visible in the code window without scrolling to it.
Philippe Mori wrote:
Otherwise, it might be related to your setup (variable height used by toolbars, lot of very long lines, in your code, zoom not at 100%, code windows too small... that might affect the result).
It could be one of those - although my set up is as close to out-the-box standard as I can imagine - but even if it is, surely it 'knows' which line needs to be shown, and should be able to ensure it is visible!
Philippe Mori wrote:
Find windows if not docked (and particulary if big) will sometime be over searched text.
Not in this case - my find window is on another screen. Again, it's simply a case of the source window not scrolling completely to show the line on which the text cursor is sitting.
___________________________________________ .\\axxx (That's an 'M')
Haven't seen this specific problem in any of the Studios... although I have yet to use VS2010 and I develop in C++ (I've developed on VS6, 2003, 2005, and 2008)... I can't imagine they would have such an obvious bug in their code, I think it has to be a configuration thing... good luck trying to figure that out! :wtf:
-
Look, I know VS2010 is a complex piece of software, and I don't expect it to be perfect. I can't quite forgive the failure to refresh the screen at times - but I can put that down to my machine at work, as it rarely if ever happens at home. But why oh why oh why when I set a breakpoint in debug, and it hits the breakpoint, does it fail to display the line it's actually broken on ?? It usually comes pretty close - within one or two lines - but I don't want to have to scroll to see where it's stopped! It does the same, occasionally, with Find - positions the cursor on the word that it's found - but doesn't scroll the window to show the line. - This happens so frequently that I find myself doing the Left-Right cursor key waggle to get the line to show almost automatically after a Find or debug break. It's so blatantly fundamentally broken!
___________________________________________ .\\axxx (That's an 'M')
I've gotten used to double clicking the first line in the callstack window - that takes you to the currently executing line.
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
Look, I know VS2010 is a complex piece of software, and I don't expect it to be perfect. I can't quite forgive the failure to refresh the screen at times - but I can put that down to my machine at work, as it rarely if ever happens at home. But why oh why oh why when I set a breakpoint in debug, and it hits the breakpoint, does it fail to display the line it's actually broken on ?? It usually comes pretty close - within one or two lines - but I don't want to have to scroll to see where it's stopped! It does the same, occasionally, with Find - positions the cursor on the word that it's found - but doesn't scroll the window to show the line. - This happens so frequently that I find myself doing the Left-Right cursor key waggle to get the line to show almost automatically after a Find or debug break. It's so blatantly fundamentally broken!
___________________________________________ .\\axxx (That's an 'M')
-
I've yet to see the breakpoint problem but the search problem drives me batty constantly. I too do the right arrow trick to scroll it into view. It's a glaring problem, I'm surprised they didn't fix it or notice it.
There is no failure only feedback
-
Look, I know VS2010 is a complex piece of software, and I don't expect it to be perfect. I can't quite forgive the failure to refresh the screen at times - but I can put that down to my machine at work, as it rarely if ever happens at home. But why oh why oh why when I set a breakpoint in debug, and it hits the breakpoint, does it fail to display the line it's actually broken on ?? It usually comes pretty close - within one or two lines - but I don't want to have to scroll to see where it's stopped! It does the same, occasionally, with Find - positions the cursor on the word that it's found - but doesn't scroll the window to show the line. - This happens so frequently that I find myself doing the Left-Right cursor key waggle to get the line to show almost automatically after a Find or debug break. It's so blatantly fundamentally broken!
___________________________________________ .\\axxx (That's an 'M')
I'm with you there. My current peeve in the "it's so freaking basic" category, however, is EF 4.1's complete lack of any hint of a unique constraint when using a code or model first approach. If you want to take over creating and updating the DB schema, you mustn't require me to circumvent your code in order to implement my chosen constraints.
-
Haven't seen this specific problem in any of the Studios... although I have yet to use VS2010 and I develop in C++ (I've developed on VS6, 2003, 2005, and 2008)... I can't imagine they would have such an obvious bug in their code, I think it has to be a configuration thing... good luck trying to figure that out! :wtf:
It isn't so much a bug as huge, glaring omission.
-
I'm with you there. My current peeve in the "it's so freaking basic" category, however, is EF 4.1's complete lack of any hint of a unique constraint when using a code or model first approach. If you want to take over creating and updating the DB schema, you mustn't require me to circumvent your code in order to implement my chosen constraints.
-
Entity Framework? you lose man points for using that crap, IMHO. Code it yerself!
___________________________________________ .\\axxx (That's an 'M')
I hope you're not serious. If so, you lose developer points for a display of ignorance. How many ORM's have you coded yourself?
-
It isn't so much a bug as huge, glaring omission.
Well, this will happen only in specific scenarios because it normally works fine. It might even be that your installation is somehow corrupted. Long lines does not seems to be a problem. Usually Visual Studio would center vertically on the desired line if the line was not previously visible and no scroll would occurs if the line is already visible. Beside that, "Find" window usually move so that the text will be visbile. Are you using fixed-width fonts? Are youy using some third-party plug-ins?
Philippe Mori
-
It isn't so much a bug as huge, glaring omission.
:laugh:
-
Thank god - I was beginning to think t was just me!
John C wrote:
I'm surprised they didn't fix it or notice it.
'Surprised' doesn't come close to my feeling!
___________________________________________ .\\axxx (That's an 'M')
I've never had this problem with the search either... wonder if its configuration or maybe just a bug in VS2010... either way, that's why I don't go to the new dev environment until at least after the first service pack...
-
Well, this will happen only in specific scenarios because it normally works fine. It might even be that your installation is somehow corrupted. Long lines does not seems to be a problem. Usually Visual Studio would center vertically on the desired line if the line was not previously visible and no scroll would occurs if the line is already visible. Beside that, "Find" window usually move so that the text will be visbile. Are you using fixed-width fonts? Are youy using some third-party plug-ins?
Philippe Mori
Philippe Mori wrote:
It might even be that your installation is somehow corrupted.
I doubt my installations on two home machines and two work machines are all corrupted. I'm using Consolas font and ReSharper.
-
I hope you're not serious. If so, you lose developer points for a display of ignorance. How many ORM's have you coded yourself?