質問

I'm in a curious situation whereby I've realising if the set breakpoint on my code then it will be triggered, otherwise the method is never called. My question is; how would setting a breakpoint on alter the way C# code would interact with a WinForms application?

The culprit seems to be ScrollableControl.ScrollControlIntoView Method. I've set the Flowlayoutpanel's autoScroll property to true, and the vertical scrollbar is visible but it still makes no difference.

Code being called only when in debug mode, and breakpoint is hit

役に立ちましたか?

解決

The call stack would make it obvious. Having to guess without one: yes, the debugger can certainly affect GUI code. Particularly so by setting a breakpoint. It is a side-effect of the focus changing from your window to the Visual Studio main window. And back. That affects code that subscribes the windows' De/Activated events, Got/LostFocus events and any code that involves painting if VS overlaps your window.

This can certainly get in the way when debugging GUI code that depends on these events. In extreme cases you may need to setup the remote debugger on another machine so this focus switching doesn't happen while debugging.

ScrollControlIntoView() is associated as well. That normally happens automatically when a control acquires the focus. This roughly answers your question, hard to see how it could be useful to actually solve your problem though. Be sure to look at the call stack to get more insight.

他のヒント

It depends on where exectly this code is. If it's in some event-handling method (say resize), or, say, painting method it could alter behaviour of your application.

That's why modern desktop for programmer should have 2 monitors, where on one you run your application on another set your breakpoints. But even in that case, you can meet some problems.

So if breakpoint in the places mantioned before, simple loggging often is more suitable solution for this kind of debugging.

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top