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

This is a discussion on Child window with active (highlighted) title bar: Possible? within the Windows Programming forums, part of the Platform Specific Boards category; Is it possible to have a child window with a title bar, and have the title bar active (i.e. highlighted ...

  1. #1
    jasondoucette.com JasonD's Avatar
    Join Date
    Mar 2003
    Posts
    278

    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.

  2. #2
    erstwhile
    Join Date
    Jan 2002
    Posts
    2,227
    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.
    CProgramming FAQ
    Caution: this person may be a carrier of the misinformation virus.

  3. #3
    jasondoucette.com JasonD's Avatar
    Join Date
    Mar 2003
    Posts
    278
    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.

  4. #4
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,859
    >>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
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  5. #5
    jasondoucette.com JasonD's Avatar
    Join Date
    Mar 2003
    Posts
    278
    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.

  6. #6
    Grammar Police HybridM's Avatar
    Join Date
    Jan 2003
    Posts
    355
    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.
    Thor's self help tip:
    Maybe a neighbor is tossing leaf clippings on your lawn, looking at your woman, or harboring desires regarding your longboat. You enslave his children, set his house on fire. He shall not bother you again.

    OS: Windows XP
    Compiler: MSVC

  7. #7
    jasondoucette.com JasonD's Avatar
    Join Date
    Mar 2003
    Posts
    278
    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.

  8. #8
    Grammar Police HybridM's Avatar
    Join Date
    Jan 2003
    Posts
    355
    Will do, I had no idea until I got the book how thick it was!
    Thor's self help tip:
    Maybe a neighbor is tossing leaf clippings on your lawn, looking at your woman, or harboring desires regarding your longboat. You enslave his children, set his house on fire. He shall not bother you again.

    OS: Windows XP
    Compiler: MSVC

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. process programming
    By St0rM-MaN in forum Linux Programming
    Replies: 2
    Last Post: 09-15-2007, 08:53 AM
  2. 6 measly errors
    By beene in forum Game Programming
    Replies: 11
    Last Post: 11-14-2006, 11:06 AM
  3. Parent not repainting Bitmp after child window closes
    By CodeX in forum Windows Programming
    Replies: 5
    Last Post: 10-05-2006, 01:03 AM
  4. Linking OpenGL in Dev-C++
    By linkofazeroth in forum Game Programming
    Replies: 4
    Last Post: 09-13-2005, 11:17 AM
  5. Invoking MSWord
    By Donn in forum C Programming
    Replies: 21
    Last Post: 09-08-2001, 05:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21