Not logged in, Join Here! or Log In Below:  
 
 News Articles Search    
 

 Home / General Programming / How do I stop ALT from triggering a menu? Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Shawn Swift

May 29, 2005, 03:47 AM

I need to stop windows from activating the file menu when a user presses alt in my game.

I know someone who has accomplished this in his game, but he insists that he did not do anything special to make it work that way. He thinks that all the apps that do it were programmmed that way intentionally because it is a standard way for apps to behave. But I'm not buying it, because lots of programmers and lazy and sloppy yet every app I try besides his game activates that file menu when you press alt.

Does anyone know what it is he might be doing different to accomplish this?

Also, I'm not using C, I am using BlitzPlus, and BlitzPlus does some management of the Windows stuff on it's own. I can run any windows function, but I can't pass function pointers to run a function in place of another in windows. I may be able to steal events from the internal event handler before it processes them. I would need to know what events to steal though.

Anyone have any ideas? This is very annoying becuase Blitz pauses the game as soon as alt is pressed. I've asked other Blitz users and they don't have any suggestions, so it looks like the only way to solve the problem is to do some more advanced tweaking of the window settings, or try to capture events.
 
Rhinoid

May 29, 2005, 04:00 AM

Hi,

the only reason ALT triggers a menu is because there is a menu to begin with.
Just try and remove the menu from the window.
You can call API calls right? Try this:

  1.  
  2. SetMenu(MyHWND, 0);
  3.  


this effectively removes any menu associated with your window.

If you have to restore the menu at one point then query the current menu first with:

  1.  
  2. OldMenuHndl = GetMenu(MyHWND)
  3.  



The API functions can be found in the User32.dll.

Cheers,

R
 
Shawn Swift

May 29, 2005, 04:13 AM

I will try that. The language has an option to disable the menu, but that doesn't seem to work for this case.

Even if that works though, I would also like the option to keep the menu while still disabling alt. In my freind's app, (a shooter called Demonstar which can be found at www.mking.com), the menu is still there, and can be activated by clicking with the mouse. That might come in handy for any number of things.
 
Shawn Swift

May 29, 2005, 04:23 AM

I just tried your suggestion, but it doesn't stop the app from pausing. There is no menu visible even without doing what you suggested, so I think I will need to use another method, perhaps one which steals keyboard input somehow.
 
Wernaeh

May 29, 2005, 05:53 AM

Hi there !

Your problem is the system menu, I guess, which is always there for normal windows ;) It not only reacts to ALT key presses, but also on the F10 key, and on right-clicking window buttons in the taskbar. Try pressing Alt and "Arrow down" after that to see the system menu.

If you were able to change the window callback function somehow, you could try catching the key events before passing to DefWindowProc, and see if that helps.

Alternatively, you might try if there is a combination of window flags which disable the system menu (i.e. SetWindowLong or a similiar call). If I remember right though, disabling the system menu will also hide the maximize and minimize buttons of your window

On a shorter note, using DirectInput also seems to avoid the system menu somehow.

Cheers,
- Wernaeh
 
Japigeman

May 29, 2005, 06:00 AM

What does your messageloop look like?
Are you using TranslateMessage()?
 
Wernaeh

May 29, 2005, 06:09 AM

Yes I use TranslateMessage(). Why do you ask? Afaik, TranslateMessage() doesn't change the parameter message, but rather just sends an additional WM_CHAR message for ASCII characters?

  1.  
  2. void CWinSys::MessagePump()
  3. {
  4.         MSG message;
  5.  
  6.         // Remove all waiting messages
  7.         while (PeekMessage(&message, hWindow, 0, 0, PM_REMOVE))
  8.         {
  9.  
  10.                 // Call window procedure
  11.                 TranslateMessage(&message);
  12.                 DispatchMessage(&message);
  13.         }
  14. }
  15.  


Cheers,
- Wernaeh
 
Wernaeh

May 29, 2005, 06:13 AM

Ahh... thanks to Japigeman, I had another look at my old windows code. The following solution up to now has worked in each of my projects =)

  1.  
  2. LRESULT CWinSys::WndProc
  3.         (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
  4. {
  5.  
  6.         // Handle incoming message
  7.         switch (uMsg)
  8.         {
  9.  
  10. /* .......................................... */
  11.  
  12.                 case WM_SYSCOMMAND:
  13.  
  14. /* .......................................... */
  15.  
  16.                         // Also, don't allow the window menu
  17.                         // to pop up.
  18.                         if (wParam == SC_KEYMENU ||
  19.                                 wParam == SC_MOUSEMENU)
  20.                         {
  21.                                 return 0;
  22.                         }
  23.  
  24. /* .......................................... */
  25.  
  26.                 break;
  27.  
  28. /* .......................................... */
  29.  
  30.         }
  31.  
  32.         // Pass on other messages to the default procedure
  33.         return
  34.                 DefWindowProc(hWnd, uMsg, wParam, lParam);
  35. }
  36.  


Thats what you get for not reviewing code that you wrote years ago =)

Cheers,
- Wernaeh
 
This thread contains 8 messages.