ShowWindow is not called when parent window is maximized

Question

1.00/5 (1 vote)

See more:

I have a modal window(1st window) inside which another window(2nd window) gets called, when 1st window is maximized it does not call for ShowWindow() function which in turn 2nd window is not launched by default and secondly when the 1st window is restored the 2nd window is launched i.e ShowWindow() is called.

Can someone tell me why when window is maximized ShowWindow() is not called? When I explicitly pass WM_SHOWWINDOW by postmessage() in initDialog() 2nd window launches.

Thanks,

Posted 24-Feb-14 2:11am

Member 10433549

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2014-02-24T04:00:00

Solution 1

It can be resolved, but why? Here is my advice: never ever show anything on top of modal window/dialog. Doing so is a clear indication that your UI design needs to be seriously and critically reviewed.

Yes, this is a typical behavior for some Microsoft applications, such as Control Panel applet in Windows, but why follow apparently bad samples of UI design? Probably Microsoft does it because they have a log of legacy code.

—SA

Posted 24-Feb-14 4:00am

Sergey Alexandrovich Kryukov

Comments

pasztorpisti 24-Feb-14 20:05pm

In my opinion showing a modal window (e.g.: by opening a modal dialog from another modal dialog) is OK, people are used to this design. Whether it is a good design or not is a good subject for debate: some software, typically "editor" programs like Blender3D have a UI design philosophy that everything should be modeless and everything is just a view to a fraction of the edited data. The input is also extremely practical: left hand - keyboard, right hand - mouse, and the keyboard events always go the the views that are under the mouse cursor. Its another problem that most people cant even place a cube inside the editor when they first open it but still, it provides one of the best user interfaces that facilitate extremely fast user interaction. Still, recently they have implemented a "classical" setup probably to attract more casual users.

Here OP probably has a different problem: He tries to solve a problem by using very ugly hack. When it comes to window messages and their order/occurrence in some specific cases (like "when this and that is maximized") then window messages get totally unpredictable and your program becomes vulnerable to window version changes, and not only windows version changes but also to changing the window manager on the same machine!!! (like aero to classical...) Message orders may change, some messages may disappear in some cases.

Sergey Alexandrovich Kryukov 24-Feb-14 20:11pm

I cannot and don't want to argue with you on this, just because this is not an extremely principle issue. Nevertheless, I would still advise what I advised, because it will be a useful practical rule and will cause minimum trouble, while having nicer design.

Do you have better advice which would keep to OP's design decision? Do you think it worth doing?

—SA

pasztorpisti 24-Feb-14 20:51pm

The problem OP is struggling with is a common problem. Window state changes (like minimizing/maximizing/showing/hiding - tied to WM_WINDOWPOSCHANGED) are often unreliable and hard to detect and they have corner cases (like different behavior for maximized windows). I've recently fixed a similar hacky code where minimizing/bringing back a window removed the maximized state from its parent (yes, the child window was also top level, dont ask why...) - that bug was also related to WM_WINDOWPOSCHANGED. WM_WINDOWPOSCHANGED is evil, I have fixed tons of bugs related to this and its better to avoid attaching event handlers to it whenever possible (especially because the windows version/window manager related differences).

From the words of OP I suspect that he uses the wrong event to show the second dialog anyway... And reading the question again I don't know what he wants to do. Using PostMessage() to send WM_SHOWWINDOW is also a bad idea, I would use SendMessage() for a more deterministic behavior.

Sergey Alexandrovich Kryukov 24-Feb-14 21:15pm

Understood...
Thank you.
—SA

Member 10433549 25-Feb-14 2:29am

Thanks for help, can you please once again see my below post.

Member 10433549 25-Feb-14 2:21am

Hello,
I think my question is not completely clear. Before I post more detail about the question I want to tell that the design is already there for long time in my application, that opening a child dialog from another modal dialog. And below is a bug that I am trying to solve.
This is how I want my application to work:
When I launch a dialog(say:Parent Dialog or 1st dialog) from my application(A) then child window(say :child dialog or 2nd Dialog) should automatically open(the child window is opened based on some application internal preference that is set).
This mentioned workflow is working fine when I launch Parent dialog or 1st dialog is in restored position, but not working(i.e child window by default is not launching) when the Parent Dialog or 1st dialog is maximized.
Code wise:
1. When Parent window or 1st dialog is in restored position then OnShowWindow() method is called which in turn calls for OnTimer() method.
2.When Parent window or 1st dialog is in maximized position then OnShowWindow() method is NOT called which in turn DOESNOT calls for OnTimer() method.

From above discussion what I understand is:
" When it comes to window messages and their order/occurrence in some specific cases (like "when this and that is maximized") then window messages get totally unpredictable and our program becomes vulnerable to window version changes, and not only windows version changes but also to changing the window manager ". Is this the root cause?
So I tired fixing by explicitly passing WM_SHOWWINDOW through SendMeaasge() or PostMessage().
1. want to know the exact root cause if possible?
2. Any other alternative to fix this?

Thanks a lot for your help.

Sergey Alexandrovich Kryukov 25-Feb-14 3:07am

This is really a dirty fix. I cannot fix it in a better way right away, I would need some work.
I only want to note that "for long time" is not a sufficient excuse to have not so good design...
—SA

Member 10433549 25-Feb-14 6:02am

Hi,
I agree with you about the design but now we don't have option to change the design so we have to fix the bug. Please suggest if you get any other fix.

Thanks,