CODEWITHSUNDEEP
visual-studiodebuggingvisual-c++breakpoints
Ali Veli
Ali Veli

Reputation: 23

Why Visual Studio gets focused although there is no breakpoint?

there is no breakpoint in my application but sometimes Visual Studio get the focus when there is no reason. (in debug mode or not in debug mode) (like there was a breakpoint)

What can be the reason?

Upvotes: 2

Views: 370

Answers (1)

Cody Gray
Cody Gray

Reputation: 244903

If the debugger isn't breaking because you've manually set a breakpoint or because the application has thrown an exception or encountered some other unexpected error, the most likely explanation is that your application is giving up the focus.

For example, you destroy the window that currently has the focus and is in the foreground before setting that focus to another window in your application. And then, because some window always has to have the focus, the window manager sets activation to the next available window, which just happens to be the one owned by Visual Studio. The resulting effect would be just as if you pressed Alt+Tab.

Raymond Chen has a blog article about this, The correct order for disabling and enabling windows:

If you are finished with a modal dialog, your temptation would be to clean up in the following order:

  • Destroy the modal dialog.
  • Re-enable the owner.

But if you do that, you'll find that foreground activation doesn't go back to your owner. Instead, it goes to some random other window. Explicitly setting activation to the intended owner "fixes" the problem, but you still have all the flicker, and the Z-order of the interloper window gets all messed up.

What's going on?

When you destroy the modal dialog, you are destroying the window with foreground activation. The window manager now needs to find somebody else to give activation to. It tries to give it to the dialog's owner, but the owner is still disabled, so the window manager skips it and looks for some other window, somebody who is not disabled.

That's why you get the weird interloper window.

The correct order for destroying a modal dialog is

  • Re-enable the owner.
  • Destroy the modal dialog.

This time, when the modal dialog is destroyed, the window manager looks to the owner and hey this time it's enabled, so it inherits activation.

No flicker. No interloper.

Upvotes: 2

Related Questions