Child window with active (highlighted) title bar: Possible?

Is it possible to have a child window with a title bar, and have the title bar active (i.e. highlighted just as a normal active window's title bar is)? I have tried to do this, even forcing focus for the child window, but the parent window remains the one whose title bar is highlighted. I realize that I could make an MDI application in which the childs of the MDI child window can have active title bars, but my application is not an MDI app.

Basically, I wish to have several windows constrained within one parent window. I have everything in place with the exception that the title bars of these child windows will not highlight. Any help is appreciated.

It would seem not - but then hopefully someone will disprove that. ;)

If the window is a child ie has WS_CHILD style and has a caption ie WS_CAPTION style then the parent window always steals the focus (SetForegroundWindow fails as i'm sure you've already discovered).

Handling WM_NCCLIENT message of a subclassed child window and using DrawCaption fails, too, as the system still seems to insist on having the parent as the active window (the caption is not drawn but it may be possible to manually 'draw' the caption area but that would involve a LOT of work, not to mention that handling the control's WM_NCCLIENT means you'll have to draw the control borders, too).

Removing the WS_CHILD style of the control causes the control to be drawn 'active' - perhaps you could 'cheat' by emulating other behaviour of the 'child' window such as ensuring it is always drawn within the client of the 'parent'?

I imagine you've probably tried out most of this stuff (and possibly more) already, though. :)

Thank you for your response, and possible solutions for my problem. I have not tried everything, yet. Before doing so, I thought I may get some interesting ideas from this board.

Handling the WM_NCCLIENT message is definitely something I would rather avoid, since it means drawing the control borders, as you mentioned. I am convinced there is a more proper way of handling this.

Basically, my windows are modeless dialog boxes, so any can be active as the user clicks from one to the next. I want them to have the behaviour of MDI applications, but they are all different dialogs, so a MDI application frame does not make sense.

I have already thought about what you mentioned regarding having them as regular windows and basically restricting their 'space' to the parent window's client area, but I am not sure exactly the best way to handle that. Restricting the clipping rectangle to the parent's client area is plausible, but my dialogs will probably have common controls that would probably ignore my requests, unless I subclassed all of them... that seems very ugly. There must be a better way. I assume that I have overlooked a simple solution. Perhaps MDI is that simple solution that just seems needlessly complicated at first.

>>but they are all different dialogs, so a MDI application frame does not make sense.

I did this but used MDI. A set number of MDI child windows covered the app client area.
Each child had diff series of controls inside it.
Each child got focus as selected.
I just locked them down so the user could not move them.

>>but I am not sure exactly the best way to handle that

I processed the WM_MOVING (before the move).
Set the dialog to where you want it, get its window rect and if the user tries to move it, put it back.

((RECT*)lParam)->left=rScreenRect.left;

ect

Thanks for the reply, novacain.

Actually, I want the user to be able to move the dialogs. I just want the dialogs to be constrained within the parent's client area in terms of painting, not moving restrictions, just as in an MDI application. For example, a window can be moved so that part of it would normally be outside of the parent's client area (if it were a real pop-up dialog box), but the only portion that is painted is that portion within the parent's client area.

So, when I said "...restricting their 'space' to the parent window's client area, but I am not sure exactly the best way to handle that...", this is what I was getting at.

It looks like that I will have to take the MDI approach. I knew this would work; I just assumed there was a simplier way.

Hey Jason,

I just recently bought Programming Windows. I noticed on petzold's website he has a link to your errata list. That's pretty cool. :)

sorry for o/t.

Yes, once I bought the book, I continually sent Petzold corrections to the text that were not already listed in his own errata list. Since he was in the middle of working on "Programming in the Key of C#" at the time, which was due to be released in a month or so, he suggested I post an errata list myself (I included his errata, and the errata from John Kopplin's list for completeness) that he could link to, instead of him updating his own errata list. I tried to add a little explanation for each erratum so it would be a little easier to understand. Let me know if you have any additions / corrections to the list. You will notice that they are all minor errors that you should really find yourself if you are paying attention :) - it really is a great book. My only regret is that I did not purchase it earlier.

Will do, I had no idea until I got the book how thick it was! :)