C# Breakpoint altering behaviour

Question

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.

Atomy

Are you sure selected!=null? – Shela

What happens if you set the breakpoint at the actual method call, instead of the conditional part? – Royall

There is a case when debugging affects program's logic. But in your case I would rather think your way of checking the method was called is erroneous. Show us more code and the way you check if it was called. – Measures

Answer 1

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.

Ammann

Thanks for the answer. This provides the background explanation of what I was seeing. – Atomy

Thanks for highlighting the focus switch. Adding a canvas refresh fixed my problem, which was occurring when I hit breakpoints via the focus switch. :) – Inch

Answer 2

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.

Synecdoche