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
debrunsonAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
debrunsonAuthor Commented:
Thank you very much, this makes sense.  Sorry for the delay, have been out of town.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.