News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Block Popup Messagebox on alt+spacebar

Started by raleep, July 25, 2012, 01:29:17 PM

Previous topic - Next topic

npnw

keyboard accelerators
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646335(v=vs.85).aspx

Enabled menuItem

http://msdn.microsoft.com/en-us/library/windows/desktop/ms647636(v=vs.85).aspx

MF_GRAYED
0x00000001L
Indicates that the menu item is disabled and grayed so that it cannot be selected.

All this to show that JJ disabled the popup menu item which was activated by the alt + space key sequence.

Hopefully all this jumping around explains what is going on in windows.

I thought it would explain JJ code.

jj2007

Thanks ;)
The second snippet
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif

works just fine and is a shorter variant of qWord's code. And it has no side effects :biggrin:

raleep

Quote from: jj2007 on July 27, 2012, 06:05:50 PM
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif

works just fine and is a shorter variant of qWord's code. And it has no side effects :biggrin:

Yes.  That works.  And this time I really do still have the minimize, maximize and close (X) buttons.

I'm curious as to where you got this.  The only thing I could find about return values from the windows procedure (specifically the WM_SYSCOMMAND notification) was:

Quote
Return Value

An application should return zero if it processes this message.

Anyway, thank you very much.

jj2007

Quote from: raleep on July 29, 2012, 09:25:41 AM
Yes.  That works.  And this time I really do still have the minimize, maximize and close (X) buttons.

I'm curious as to where you got this.
...
From good ol' Win32.hlp:
A window receives this message when the user chooses a command from the window menu (also known as the System menu or Control menu) or when the user chooses the Maximize button or Minimize button.
...
SC_KEYMENU   Retrieves the window menu as a result of a keystroke


So if you suppress that message, the menu will not be triggered by a keystroke...

QuoteAnyway, thank you very much.

My pleasure :icon14:

qWord

Quote from: jj2007 on July 27, 2012, 06:05:50 PM
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif

... And it has no side effects :biggrin:
AFAICS you can't control the menus with the keyboard anymore.
For common windows it also needed to call DefWindowProc - otherwise it is not possible to move, resize, maximize and minimize the window.
MREAL macros - when you need floating point arithmetic while assembling!

raleep

#20
Quote from: jj2007 on July 29, 2012, 09:39:10 AM

I'm curious as to where you got this.

Quote...
From good ol' Win32.hlp:
A window receives this message when the user chooses a command from the window menu (also known as the System menu or Control menu) or when the user chooses the Maximize button or Minimize button.
...
SC_KEYMENU   Retrieves the window menu as a result of a keystroke


So if you suppress that message, the menu will not be triggered by a keystroke...

But where do you get the "return 1"?  Why not return -1 or return 456789?

:idea: Ok, I get it (I think).  Returning anything but 0 prevents the os from processing the key, although that's not what I would expect from:

QuoteReturn Value

An application should return zero if it processes this message.

jj2007

Quote from: qWord on July 29, 2012, 09:57:35 AM
Quote from: jj2007 on July 27, 2012, 06:05:50 PM
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif

... And it has no side effects :biggrin:
AFAICS you can't control the menus with the keyboard anymore.
For common windows it also needed to call DefWindowProc - otherwise it is not possible to move, resize, maximize and minimize the window.

On my puter my code just works fine (XP SP3). Maybe something is wrong with your Windows installation.

qWord

Quote from: jj2007 on July 29, 2012, 05:50:03 PM
Quote from: qWord on July 29, 2012, 09:57:35 AM
Quote from: jj2007 on July 27, 2012, 06:05:50 PM
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif

... And it has no side effects :biggrin:
AFAICS you can't control the menus with the keyboard anymore.
For common windows it also needed to call DefWindowProc - otherwise it is not possible to move, resize, maximize and minimize the window.

On my puter my code just works fine (XP SP3). Maybe something is wrong with your Windows installation.
The attached EXE won't work on Win7,x64. Maybe I've misunderstood your snippet.
MREAL macros - when you need floating point arithmetic while assembling!

Ryan

#23
Is this a window proc versus dialog proc issue?

A dialog proc should return TRUE (1) if it handles the message, otherwise FALSE (0).

A window proc should return 0 if it handles the WM_SYSCOMMAND message, otherwise DefWindowProc needs to be called.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms646360%28v=vs.85%29.aspx

jj2007

qWord,
Most HLL including Masm use, in a WndProc, the SWITCH/CASE/ENDSW construct followed by a call to DefWindowProc:
SWITCH uMsg
...
CASE WM_SYSCOMMAND
.if wParam==SC_KEYMENU
return 1
.endif
...
ENDSW
invoke DefWindowProc, hWnd, uMsg, wParam, lParam


This construct can be left e.g. by mov eax, 1 + ret, thus avoiding the call to DefWindowProc. Your code never called DefWindowProc for the WM_SYSCOMMAND message, and therefore blocked everything related to the SYS_MENU.

qWord

Quote from: jj2007 on July 30, 2012, 01:50:41 AMMost HLL including Masm use, in a WndProc, the SWITCH/CASE/ENDSW construct followed by a call to DefWindowProc
no, commonly DefWindowProc() is called from the default case.
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Quote from: qWord on July 30, 2012, 03:56:46 AM
Quote from: jj2007 on July 30, 2012, 01:50:41 AMMost HLL including Masm use, in a WndProc, the SWITCH/CASE/ENDSW construct followed by a call to DefWindowProc
no, commonly DefWindowProc() is called from the default case.

commonly? I like it empirically :biggrin:

356 files found
#file   default endsw   defpro  file
+#59    0       4776    4796    \masm32\examples\enumerate\enumdd\enumdd.asm
+#73    7055    7066    7683    \masm32\examples\exampl01\generic\generic_with_global_vars.asm
+#149   3933    4285    4305    \masm32\examples\exampl03\timer\timer.asm
+#202   0       7830    10871   \masm32\examples\exampl05\hlldemo\smalled\redit.asm
+#218   0       6239    6991    \masm32\examples\exampl05\scroll\scroll.asm
+#222   0       7198    8100    \masm32\examples\exampl05\switch\switch.asm
+#234   0       3827    3847    \masm32\examples\exampl06\barchart\barchart.asm
+#269   3860    5883    5903    \masm32\examples\exampl07\ani\ani.asm
+#281   4831    8052    8879    \masm32\examples\exampl07\mangled\mangled.asm
-#287   0       3633    0       \masm32\examples\exampl07\sdw\sdw.asm
+#313   4286    10931   15768   \masm32\examples\exampl07\skins3\skins3.asm
+#321   4797    8043    9476    \masm32\examples\exampl07\ttbar2\ttb2.asm
+#337   0       5467    6094    \masm32\examples\threads\multhread\multhrd.asm
+#346   4434    7319    7974    \masm32\examples\unicode_extended\uwin2\uwin2.asm
+#356   5275    9376    10331   \masm32\examples\unicode_generic\template\template.asm
15 files used SWITCH
14 =     93.0% had DefWindowProc after the ENDSW
1 =      6.7% had DefWindowProc between DEFAULT and ENDSW

qWord

Ich vertraue nur Statistiken die ich selbst gefälscht habe!
:bgrin:
MREAL macros - when you need floating point arithmetic while assembling!

jj2007

Actually, sdw.asm is a "false negative", so it's 100% :P

Ryan