Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 518
  • Last Modified:

Controls on dialog-based program remain active when main window loses focus

I have built a dialog-based program in MFC / C++.  It works fine.  It has a menu bar, a tool bar, and a tab control.  The problem is that when I run my program, then switch to a different window (any window), certain controls on my original dialog do not deactivate.  The main dialog itself deactivates, but all it takes is one click on the menu, toolbar, or one of the tabs, and they fly into action, just as though the main dialog is totally active.  Obviously this is not "normal" Windows behavior.  Generally you have to click on a window (anywhere) to activate it, then click on the control or function that you wish to use.  Can someone tell me what is going on?

Thank you
0
debrunson
Asked:
debrunson
  • 2
1 Solution
 
chaauCommented:
Why do you think it is not normal behaviour? I have just opened "Date and Time" control panel and switched to the browser window (this window) to type the response. Now: all it takes is a single click on "Additional Clocks" tab page in the "Date and Time" Control panel applet to "fly it into action". I think that was a normal behaviour from as long as I remember Windows
Date and Time
0
 
debrunsonAuthor Commented:
After further investigation it looks like this phenomenon is application-dependent.  Office products (Word, Excel, Powerpoint) work in the way that I described above.  I guess that's what gave me the idea that this is normal.  If any of those windows are deactivated, they must be reactivated before menus and toolbars become functional.  But other things (like Solidworks, Photoshop, Acrobat Pro) don't behave that way.  If they are deactivated, it only takes one click for the menus to pop up, etc.  I thought there was a Window convention for this sort of thing but apparently not???
0
 
sarabandeCommented:
you can decide yourself whether your controls should immediately react when they are clicked on or not. if the dialog would handle the WM_ACTIVATE and WM_ACTIVATEAPP messages, it would get notified whenever an outside window becomes active and also when the control goes back to the dialog. if you want you could disable/enable the controls and enforce a wished behavior when handling those messages. you also can find out whether it is a change between windows of the same input queue or not.

if the dialog is modeless (dialogs using tab controls often have a modeless parent window)  the behavior you described is standard behavior because modeless dialogs often are part of other dialogs and sometimes you even can't identify them as separate dialogs. also modeless dialogs share the same message queue with other windows in the application.

Sara
0
 
debrunsonAuthor Commented:
Thank you very much, this makes sense.  Sorry for the delay, have been out of town.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now