WM_SYSCOMMAND oddities

泪湿孤枕 提交于 2020-01-15 09:54:20

问题


An application recieves the WM_SYSCOMMAND message when the user selects a menu item command on the system menu, and so wParam can be SC_CLOSE, SC_CONTEXTHELP, SC_MAXIMIZE, SC_MINIMIZE, SC_RESTORE etc. That's logical. (Of course you can also send these messages by clicking on the minimize, maximize, close buttons etc.)

But one can also send the WM_SYSCOMMAND message to send commands to the Windows Shell. For instance, one can display the start menu (SC_TASKLIST), activate the screen saver (SC_SCREENSAVE), and turn off the monitor (SC_MONITORPOWER). This does not make sense, does it? What does this have to do with the application's system menu? This is more of a "system command", i.e. more of a completely other interpretation of the name "WM_SYSCOMMAND" of the message. It's like the message is used to send command requests to the system.

Why is this message used for two seemingly entirely different things, and what thing does the name "SYSCOMMAND" refer to (command on the system menu, or command of the operating system)?


回答1:


A window receives this message when the user chooses a command from the Window menu (formerly known as the system or control menu) or when the user chooses the maximize button, minimize button, restore button, or close button.

These WM_SYSCOMMANDs (maximize, minimize, restore, close, and the ones in the system menu) may be sent to your window when the user uses the system menu or the caption buttons. I believe (my Win32 is very rusty) these are normally handled by DefWindowProc which does all the dirty work and then sends a notification to your window (WM_SIZE/WM_SIZING, WM_CLOSE, etc.).

Now, further down (hidden in the blurb at the bottom):

An application can carry out any system command at any time by passing a WM_SYSCOMMAND message to DefWindowProc. Any WM_SYSCOMMAND messages not handled by the application must be passed to DefWindowProc.

You can also execute a particular WM_SYSCOMMAND by sending it to the DefWindowProc. These include the ones mentioned above, but they also include additional ones such as SC_SCREENSAVE and SC_TASKLIST. I have no idea what kind of path through DefWindowProc something like SC_SCREENSAVE would take to eventually end up triggering the screensaver, but that's how it is.

So the way I see it is the entire class of WM_SYSCOMMANDs are system commands. It's just that some of them (the ones accessible from a window's caption) are sent to the window and others are sent by the window at your discretion.




回答2:


WM_SYSCOMMAND is just the system version of WM_COMMAND, and it follows the same semantics. The WM_COMMAND message is sent to your application when the user selects an item from a menu, clicks a button, selects a radio button, etc. The ID parameter indicates what was clicked. The command may also be sent manually, using SendMessage() or PostMessage().




回答3:


This is the legacy of 16 bits of Windows.

Please google the article by Bob Gunderson:《GetMessage and PeekMessage Internals》,Microsoft Developer Network Technology Group,December 11, 1992

In the period of Windows 3.1, the operation system was non-preemptive and single-threaded. When GetMessage/PeekMessage function accessed the system queue and encountered CTRL-ESC key down, a WM_SYSCOMMAND message was posted to the active application (remember it was a single-threaded system) with SC_TASKLIST in wParam. The key down event was directing Windows to display the task manager window.



来源:https://stackoverflow.com/questions/2755202/wm-syscommand-oddities

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!