Title Bars: Is Getting Rid Of Them Possible?

I have an SDK program that displays several child window controls on top of a parent window.

I would love to get rid of the title bar ( that thin blue strip on top ).

I tried declaring the parent window with the WS_DLGFRAME style, but the title bar was still there.  Maybe I have to change other parameters in the CreatWinow() call ???

Any ideas?  Is this possible?
viharaAsked:
Who is Participating?
 
nietodCommented:
You just need to create them without the WS_CAPTION Style.  (the title bar is really propperly called the caption.)
0
 
nietodCommented:
Note that some other window styles are a combination of of window styles and might "secretly" contain the WS_CAPTION style (this is documented, it isn't a real secret, but you might miss this fact if you don't loop up the styles).  for example, the WS_OVERLAPPEDWINDOW style includes the WS_CAPTION style.

let me know if you have questions.
0
 
viharaAuthor Commented:
I haven't used WS_CAPTION and I checked for it in the specs.  It seems like the only choices for a parent window without a title bar is WS_DLGFRAME.  The msvc++ specs said it doesn't have a title bar, but I got a thin blue strip ( since the min/max buttons ) at the top anyway.

What other style for a parent window do you recommend?  Here is the code for my Create Window call.  Perhaps I am missing something?

 hwnd = CreateWindow (
                                       szAppName,                 // window class name
                        NULL,                        // window caption
                        WS_DLGFRAME,       // window style            
                                       smCxScreen / 4,          // initial x position
                                        0,                               // initial y position
                                       smCxScreen / 2,          // initial x size
                                       cyChar * 30,                // initial y size
                                       NULL,                         // parent window handle
                                       NULL,                          // window menu handle
                                      hInstance,                    // program instance handle
                        NULL
                                   ) ;            
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
nietodCommented:
since windows 95 dialogs have all had captions so the DLGFRAME now implies a caption.  If you want a window with a border, but that cannot be sized, use WS_BORDER.  If you want the border to be sized, use WS_THICKFRAME.
0
 
viharaAuthor Commented:
Neither worked.  I still got that blue bar at the top.  I guess it can't be done in Win95.

Maybe I can learn to live with the title bar.  Is it possible to paint it a differnt color?
( if so, could you give a quick example?)
0
 
nietodCommented:
It can be done, it IS done, I do it.  (it also possible to paint it, but I don't think that is what you really want).

Now I notice that the you are not specifying the WS_CHILD style and you are not specifying the a parent window handle.  Neither are needed for this, but you originally said this is for a child window.  Well, that isn't making a child window, did you post the wrong code?
0
 
viharaAuthor Commented:
Sorry.  I guess I wasn't clear.  The program in a windows sdk program consisting of a parent window with several child windows.   I want the parent window to have no title bar ( or a differnt look ).


0
 
nietodCommented:
The following code works for me to create a window with a border and no caption.  it does use the WS_DLGFRAME, so apparently I was wrong about that since this works fine.  (Although I thought I had used WS_BORDER instead througout my code, apparently I missed this one.)

   SplWndHnd = CreateWindow("QSplWndCls",        // Create the splash window.
                            "Novaware",
                            WS_POPUP | WS_DLGFRAME | WS_VISIBLE,
                            WndLft,WndTop,WndWdt,WndHgt,
                            NULL,NULL,GetModuleHandle(NULL),NULL);

Note that this is for a pop-up window, not a child window.  I create them as child windows too (most child windows don't have captions) and it works fine.  but I don't have decent examples to post.
0
 
viharaAuthor Commented:
It worked!  The additon of WS_POPUP made the title bar disappear.  I noticed however, that I couldn't move the window with the mouse cursor.  I tried substituting some other styles in but had no luck.

Is it possible to have title bar and be able to move the window? ( if so how?)
0
 
nietodCommented:
The addition of the WS_POP style is needed if this is not a child window.  Is that what you want?  That means the window can be moved outside of the owning window's frame.  (if it is allowed to move, or if the owner is moved it will leave this window "behind" and in this way the window canl be moved out of the owner's frame.)  You should specify the WS_CHILD style instead of WS_POP style if you really want a child window.  Then the window will be confined to the parent window's client area.

If you want to be able to resize the window with the mouse, you can add the WS_THICKFRAME style.  This is akin to moving the window with the mouse, but not identical--i.e. it can be used to move the window, but indirectly.  You cannot move the window with the mouse because it has no caption.  That is the area that you would grab with the mouse to move the window.  You can restore this ability by providing another area for the user to grap, if you desire. To do this you would have to process the WM_NCHITTEST message.
0
 
nietodCommented:
I didn't see

>> The program in a windows sdk program consisting of a parent
>> window with several child windows.   I want the parent window to
>> have no title bar ( or a differnt look ).
Then you do want the WS_POP up style and you do not want to specify a parent/owner window (both of which you seem to have correct, my suggestiosn regading them were assuming this was for a child window).
If you want the user to be able resize the window, (recomended) use the thickframe style.
I would also recomend that you provide a place for them to grab the window to move it.  
0
 
viharaAuthor Commented:
Thanks again.  The window looks SPECTACULAR without the title bar, but it would look worse with a homemade place to move it ( not to mention the work ).......and not being able to move windows is a pet peeve of mine.

Is it very hard to change the color of the title bar.

*Chuckle*  If you give me an example I'll give you your points and leave you alone :)

You have been a tremendous help

0
 
nietodCommented:
>> Is it very hard to change the color of the title bar?
That depends.  If you want to draw an entirely custom caption, then that is not too pad (but some work).  If you want to draw a caption that is similar to the standard, but with a difference or two, that is a lot of work.  For example, I recently helped someone make windows where the caption title was centered, rather than on the left..  What was tough was in placing (determining the position and size of) and drawing in all the other elements of the window, like the frame, the buttons at the top, the icon on the corner etc.  That is a good bit of work.  I wouldn't recomend it unless you have a good reason to do it.  
However, if you just wanted to draw a custom caption that didn't look at all like the windows one and didn't have buttons etc, that would not be too hard.

Let me ask you though, what exactly is your goal here?  How is this window supposed to function?  How is the user supposed to interact with it.  Should it have close boxes etc?

0
 
viharaAuthor Commented:
Well.  It is a quiz game.

The parent window holds various child controls to implement the game.

I wanted the game to look a bit more decorative and differnt then the std gray/blue program barfed out by the msvc++ appwizard.

I've used some custom colors and bitmaps and it looks nice.  It is just that blue title bar spoils the look.   I would be willing to settle for just changing that blue background color.

I can almost live with no title bar as I have taken pains to size and place the parent window with regards to the user's screen.........so I don't really need resizing.  However, I am one of those people who get annoyed when I can't move a window.  I think adding in my own graphic to move a barless window would spoil the look more then having the title bar there.

Like I said if there was a reasonable way to change the title bar to green ( or another color) from its native blue I would have the best of both worlds

0
 
nietodCommented:
>> reasonable way to change the title bar to green ( or another
>> color) from its native blue I would have the best of both worlds
If you let windows draw the caption, window will draw it in its standard color (which you can change, but you mst change for all windows, not just yours)  The other choice is to draw the caption yourself, there is no in between option.  

Your choices are:
A) leave the window unmovable--a pain for the user.
B) Restore the caption and let the windows draw it in the standard colors (which the user has choosen)
C) Restore the caption and paint it yourself.  this can be hard.
D) provide an alternate "handle" for the user to grab to move the window.  This could be something inside the window area, or it could be the window frame.  For example you could let the left and top edges move (instead of resize) the window and let the bottom and right edges still resize it.  Note this sort of "playing" with the UI is discouraged, but so is creating overlapped windows without captions...
0
 
viharaAuthor Commented:
Excellent.  I dont mind blowing all of my points.  You gave me some fast, GOOD answers very quickly.

The idea of using the parent window border for grabbing/moving sounds neat, but writing my own code to move the window sounds complex and more work then I want to do.

I will flip a coin at a some point or ask the organization I'm building it for tell me which they prefer.

Thanks again for the good background info and all the help
0
 
nietodCommented:
>> The idea of using the parent window border for grabbing/moving sounds
>> neat, but writing my own code to move the window sounds complex and
>> more work then I want to do.
Its nearly trivial.  Hook the WM_NCHITTEST message and pass the message to the default window procedure.  then test the value the defautl window procedure returns, if it is HTTOP, HTLEFT, or HTTOPLEFT then convert it to HTCAPTION before returning.  All other values you return unchanged.  That is it!  You don't even have to look at the mouse coordinates!
0
 
viharaAuthor Commented:
*Chuckle*  This is my first real SDK program fresh out of studying Pezold.

It may be trivial to you, but for me its "some fancy shooting".

Could you give me a quick example of the WS style I would use and the syntax of setting that up?  What you are describing is all brand new to me
0
 
nietodCommented:
Same window style as now, but you would have code (C++) like

case WM_NCHITTEST:
{
   LRESULT HitVal = DefWindowProcedure(hWnd,Msg,wParam,lParam);

   if (HitVal == HTTOP || HitVal == HTLEFT || HitVal == HTTOPLEFT)
      HitVal = HTCAPTION;
   return HitVal;
}

The code just intercepts the hit test message which tries to detemine where the mouse is over the window.  It lets the default window procedure figure out where the mouse is, and then if the mouse is on the top or left edges  or the top-left corner it "pretends" the mouse is overthe caption.  everything else will be automatic.
0
 
viharaAuthor Commented:
Well;

I put this in my CreateWindow() call

WS_POPUP | WS_DLGFRAME | WS_VISIBLE

I put this in my switch(iMsg) structure in my WndProc()
( the compiler didn't like DefWinProcedure so I changed it to DefWinProc() )

It compiled, but it doesn't move when I try to grab it at the border with the mouse.
Does the parent window need the focus for it to move?  I have my game set up to give focus to the child controls so the user can tab around them


case WM_NCHITTEST:
{
   LRESULT HitVal = DefWindowProc(hwnd,iMsg,wParam,lParam);
   if (HitVal == HTTOP || HitVal == HTLEFT || HitVal == HTTOPLEFT)
   {
     HitVal = HTCAPTION;
    return HitVal;
}
0
 
nietodCommented:
>>Does the parent window need the focus for it to move?
No.  Make sure that the code is being run.  You can use a debugger or use Spy++ to see if the hit test values are being altered for these cases.
0
 
viharaAuthor Commented:
It works.  The problem was the if conditional.

Instead of :
                 if( HitVal == blah || HitVal == yakyak )

it should of been:
               if ( HitVal == blah || yakyak )

I really appreciate your help.  You have taught me a LOT in answering this question and probally some things I will not find covered in the text books.  

Like I said I'm building the program to look differnt because I just finnished school in December and an entry level windows programmer is about as popular as a freshly graduated med student with no residency or experience.

I spent the last few month reading Petzold's PROGRAMMING WINODWS95 ( next is the book by the same title written by proisse for mfc ).  

My program is designed to showcase the skills I picked up from studying this book on myown outside of a class.   I am grateful for this maneuvar you showed me.  I'm sure it will look impressive coming from a new programmer.

Now I have to think about the philosophical issues of breaking away from the standard UI that you brought up.  On the one hand its MY program and the USERS pc, can copy of win95/NT.  If we all want a differnt look then who cares?   On the other hand I was a lab assistant before my school's lab got windows.  I remember how hard life was for people learning new apps without a unified user interface.

Oh well, I guess this just means that I am turning into a geek to be thinking about these things :)

Thanks again for the fancy moves!
0
 
nietodCommented:
>>Instead of :
>>                      if( HitVal == blah || HitVal == yakyak )
>>
>>     it should of been:
>>                    if ( HitVal == blah || yakyak )
No, it should be the former.  In fact the later case will allways be true, so a mouse press anywahere will move the window.
0
 
viharaAuthor Commented:
I noticed........and I liked that!:)  ( anwhere on my window that is, not on the screen )

What you say is peculair becuase I couldn't get the if conditional to kick over it its first form.  

Anyway, thanks again


0
 
nietodCommented:
If you want to keep it like that, then take out the call to the default window procedure and take out the "if".  Just return HTCAPTION in all cases.

If you want the make it work the other way (which allows the user to resize) then use the code I suggested originally.  I think the problem you might have had with it was that you didn't have the WS_THICKFRAME style, which adds a "sizing frame" to the window.  Specify that style and the  original code shoudl work.

Another option, a hybred is to let the 4 edges do the sizing and let the interior be used to move the window.  For that, change the if to look for HTCLIENT and change it to HTCAPTION.
0
 
viharaAuthor Commented:
Bingo.  I didn't use WS_THICKFRAME  ( I initalize the widow in proportion to the user's client area and want to keep that look ).

This extra info is another bonus.  Im saving this page into my programming notes.

Thanks again

Steve

0
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.

All Courses

From novice to tech pro — start learning today.