How to make a full screen window

I write in plain C to the WIN32API. None of that fancy stuff.

I need to be able to have the client area of a window fill the screen such that the window frame, title bar and menu are all invisible.

In the past I sized and positioned the window so that the invisible areas would simply be drawn off-screen, but in this age of common multi-monitor systems, this is no longer a good option because those previously invisible elements are appearing on adjacent displays!

I DO NOT want to lose the functionality provided by the menu or the title bar buttons. (That functionality still existed even when they were drawn off screen.) That means that I cannot simply adjust the window style to no title, no menu and no frame when it goes full screen. Instead, I suspect that I need to somehow alter the height of the title and menu to zero (the frame I can turn off) when the program is full screen and then restore their normal height later.

Is this even possible and if so, how is it done? If it is NOT possible, then what is the correct procedure for making a window full screen?

And remember, I'm talking about doing this with my CODE, not to an existing 3rd party window or anything. I know about things like pressing F11 in a browser, but I need to implement the code behind the F11!

If you want full-screen functionality as implemented in most applications, that's it: in full screen-view you have to remove caption as well as the menu bar.
Here is a brief example how to toggle between normal and full-screen view:

Code:

---

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
  int wmId, wmEvent;
  // ...
  switch (message)
  {
  case WM_COMMAND:
      wmId = LOWORD(wParam);
      wmEvent = HIWORD(wParam);
      // Parse the menu selections:
      switch (wmId)
      {
      case ID_VIEW_FULLSCREEN: // toggle full screen
        if(g_bFullScreen)
            _ViewNormal(hWnd);
        else
            _ViewFullScreen(hWnd);
        break;
        //...
      //...
  //...

---

Code:

---

void _ViewFullScreen(HWND hWnd)
{
  // keep in mind normal window rectangle
  ::GetWindowRect(hWnd, &g_rcNormal);

  // remove caption and border styles
  DWORD dwOldStyle = ::GetWindowLong(hWnd, GWL_STYLE);
  DWORD dwNewStyle = dwOldStyle & ~(WS_CAPTION | WS_THICKFRAME);
  ::SetWindowLong(hWnd, GWL_STYLE, dwNewStyle);

  // remove the menu bar
  ::SetMenu(hWnd, NULL);

  // resize to full screen view
  // NOTE: use SWP_FRAMECHANGED to force redraw non-client
  const int x = 0;
  const int y = 0;
  const int cx = ::GetSystemMetrics(SM_CXSCREEN);
  const int cy = ::GetSystemMetrics(SM_CYSCREEN);
  ::SetWindowPos(hWnd, HWND_TOPMOST, x, y, cx, cy, SWP_FRAMECHANGED);

  // set full screen indicator
  g_bFullScreen = TRUE;
}

---

Code:

---

void _ViewNormal(HWND hWnd)
{
  // put caption and border styles back
  DWORD dwOldStyle = ::GetWindowLong(hWnd, GWL_STYLE);
  DWORD dwNewStyle = dwOldStyle | WS_CAPTION | WS_THICKFRAME;
  ::SetWindowLong(hWnd, GWL_STYLE, dwNewStyle);

  // put back the menu bar
  ::SetMenu(hWnd, g_hMenu);

  // resize to normal view
  // NOTE: use SWP_FRAMECHANGED to force redraw non-client
  const int x = g_rcNormal.left;
  const int y = g_rcNormal.top;
  const int cx = g_rcNormal.right - g_rcNormal.left;
  const int cy = g_rcNormal.bottom - g_rcNormal.top;
  ::SetWindowPos(hWnd, HWND_NOTOPMOST, x, y, cx, cy, SWP_FRAMECHANGED);

  // reset full screen indicator
  g_bFullScreen = FALSE;
}

---

Further, to keep some functionality provided by the menu or the title bar buttons when in full-screen view mode, you can use accelerators and/or context menus.

I have attached here a simple demo application.

Quote:

---

Originally Posted by ovidiucucu

If you want full-screen functionality as implemented in most applications, that's it: in full screen-view you have to remove caption as well as the menu bar.
[...snip...]
Further, to keep some functionality provided by the menu or the title bar buttons when in full-screen view mode, you can use accelerators and/or context menus.

---

Thanks for trying, but I've got all of that done and working already (if that wasn't clear, I apologize.) But accelerators are not the same as menu hot-keys. An accelerator is a single key or chord (e.g. 'F' or 'Ctrl+Alt+F') but a menu hot-key sequence is, well, a sequence of individual keys (e.g. 'Alt', 'V', 'T', 'M', in sequence to toggle menu visibility in Firefox.) There may be an accelerator associated with a sequence, but they are absolutely NOT equivalent, because the sequences can act as a mnemonic to help the user to remember things, which is why they are often used in training programs.

Since the existing menu code in Windows already knows how to process those sequence for me, I'm trying not to lose that functionality AND to avoid recreating that entire portion of the menu system myself, just to get back something that already exists because Microsoft has wrongly decided that an invisible menu has no value.

My best work-around to Microsoft's oversight is to activate and show the menu when the mouse approaches the top edge of the display. I'm hoping to improve that by also activating the menu when the 'Alt' key is pressed, but I need to ensure that it is also processed by the menu and I need to figure out when to hide/remove the menu again. It seems that there is no good way to do this, which is why I asked -- just in case someone had discovered a secret or little known Windows function or option that allowed a menu to be invisible or even just to be draw zero or one pixel high.

Well, did you try to expand the normal frame window to have the menu bar and borders gone off the sight? Maybe the secret knowledge you're looking for is the fact that window coordinates are allowed to be negative.

From my original question:

Quote:

---

In the past I sized and positioned the window so that the invisible areas would simply be drawn off-screen, but in this age of common multi-monitor systems, this is no longer a good option because those previously invisible elements are appearing on adjacent displays!

---

If that isn't clear enough: Simply moving parts of a window off the edge of a screen is no longer valid because there may ALWAYS be another screen attached to that edge. I have a machine with two screens configured one ABOVE the other and one with three screens configured in a horizontal row. When my program is "fullscreen" it should completely consume ONE of the displays and draw ABSOLUTELY NOTHING on any other display (except perhaps a floating dialog, but that's outside the scope of my question.)
Toggling the menu's existence (and therefore its visibility) in response to the mouse location has satisfied the customer -- so far. But I still wish there was a standard way to have the menu still watching the keyboard even though it isn't being drawn, since Microsoft already took care of writing THAT code (as well as the code to load a menu resource and use the hot-key information it contains to translate those key sequences into menu commands.)

Quote:

---

Originally Posted by nurbles

[...] I asked -- just in case someone had discovered a secret or little known Windows function or option that allowed a menu to be invisible or even just to be draw zero or one pixel high.

---

For sure nobody had discovered something like that simply because does NOT exist. A window may have or may have not a menu, and not a visible or invisible one.

Quote:

---

For sure nobody had discovered something like that simply because does NOT exist. A window may have or may have not a menu, and not a visible or invisible one.

---

That's why I consider it an oversight by Microsoft. It never occurred to them that someone would want (or need) the KEYBOARD functionality of a menu to be active/available but without the VISUAL/MOUSE aspects. But as anyone who has done serious phone support can tell you, it is FAR easier to tell someone (or to document) Tap ALT, then tap F, then X than it is do describe all of the visual and physical aspects of using the mouse to click a menu item. If you don't believe me, try explaining that over the phone to someone who is using a computer for the very first time and/or knows NONE of your terminology:

You: Use the mouse--
Them: What's a mouse?
You: See the thing that looks kinda like a bar of soap, possibly with a wire coming out of it?
Them: No
You: Do you see a flat area on the keyboard that looks kinda like a nearly square drink coaster?
Them: No
You: How about a thing with a ball on top that you can move without the ball rolling away?
Them: I think I see that.
You: If you move the ball while watching the screen, do you see something (probably a little arrow) moving around?
Them: It isn't always an arrow, but I think so.
You: Ok, use the ball to move that arrow/thing to the menu.
Them: What's a menu?
etc.

You then need to describe concepts like window, caption, menu, and more, just to help them open a file. If the menu has hotkeys defined (as all good menus do) you would just say, "Press these keys, in sequence, one at a time: Alt, F, O"

I just wish Microsoft would allow me to use the code they already wrote and included in the menu control that loads a hotkey/command set (i.e. "a menu resource") and handles all of the key processing necessary.

But since Microsoft is apparently more interested in turning my desktop into a huge smartphone, with NO keyboard or mouse, just a touchscreen, I don't see any progress being made on my behalf. So I'm done here. Sorry if I was a bother to anyone.

Quote:

---

That's why I consider it an oversight by Microsoft.

---

What you call an oversight somebody else could call a design option. It's not possible to comply with opinion of every single person in the world. If an OS misses something what you need, you just implement it yourself. If you really need that menu activation, you just set a keyboard hook to detect pressing ALT, and return the menu back to window. (Maybe I'll try to make a demo somewhat later.) Or you just provide a real accelerator combination to every menu item that you consider to be worth that and not overseen. ;)

Quote:

---

Originally Posted by nurbles

[...]
Them: What's a mouse?
[...]
Them: What's a menu?
etc.

You then need to describe concepts like window, caption, menu, and more, just to help them open a file. If the menu has hotkeys defined (as all good menus do) you would just say, "Press these keys, in sequence, one at a time: Alt, F, O"
[...]

---

"Them: What are keys?" :)

C'mon, today's users, even kids, know what's a mouse or "concepts" like window, caption, menu, and more.
Beside selecting a menu item (from the main menu or from a context one) with the mouse or pressing Alt plus a sequence of keys, they know using of keyboard shortcuts as well (like Ctrl+O, in your example).

Have a look in my signature and replace "When in Rome, do as Romans do" with "When program for Windows, follow/use the Windows design, concepts and behaviors".
Of course, you can change them in your application with your own, but generally that can make most of Windows users more confused or at least may look weird in most users' eyes.