Private AHK messages

[just me]

Code: Select all

// WM_USER is the lowest number that can be a user-defined message.  Anything above that is also valid.
// NOTE: Any msg about WM_USER will be kept buffered (unreplied-to) whenever the script is uninterruptible.
// If this is a problem, try making the msg have an ID less than WM_USER via a technique such as that used
// for AHK_USER_MENU (perhaps WM_COMMNOTIFY can be "overloaded" to contain more than one type of msg).
// Also, it has been announced in OnMessage() that message numbers between WM_USER and 0x1000 are earmarked
// for possible future use by the program, so don't use a message above 0x1000 without good reason.
enum UserMessages {AHK_HOOK_HOTKEY = WM_USER, AHK_HOTSTRING, AHK_USER_MENU, AHK_DIALOG, AHK_NOTIFYICON
	, AHK_RETURN_PID, AHK_EXIT_BY_RELOAD, AHK_EXIT_BY_SINGLEINSTANCE, AHK_CHECK_DEBUGGER
	// Allow some room here in between for more "exit" type msgs to be added in the future (see below comment).
	, AHK_GUI_ACTION = WM_USER+20 // Avoid WM_USER+100/101 and vicinity.  See below comment.
	// v1.0.43.05: On second thought, it seems better to stay close to WM_USER because the OnMessage page
	// documents, "it is best to choose a number greater than 4096 (0x1000) to the extent you have a choice.
	// This reduces the chance of interfering with messages used internally by current and future versions..."
	// v1.0.43.03: Changed above msg number because Micha reports that previous number (WM_USER+100) conflicts
	// with msgs sent by HTML control (AHK_CLIPBOARD_CHANGE) and possibly others (I think WM_USER+100 may be the
	// start of a range used by other common controls too).  So trying a higher number that's (hopefully) very
	// unlikely to be used by OS features.
	, AHK_CLIPBOARD_CHANGE, AHK_HOOK_TEST_MSG, AHK_CHANGE_HOOK_STATE, AHK_GETWINDOWTEXT
	, AHK_HOT_IF_EXPR	// L4: HotCriterionAllowsFiring uses this to ensure expressions are evaluated only on the main thread.
};
// NOTE: TRY NEVER TO CHANGE the specific numbers of the above messages, since some users might be
// using the Post/SendMessage commands to automate AutoHotkey itself.  Here is the original order
// that should be maintained:
// AHK_HOOK_HOTKEY = WM_USER, AHK_HOTSTRING, AHK_USER_MENU, AHK_DIALOG, AHK_NOTIFYICON, AHK_RETURN_PID

Message numbers in the second range (WM_USER through 0x7FFF) can be defined and used by an application to send messages within a private window class. These values cannot be used to define messages that are meaningful throughout an application because some predefined window classes already define values in this range. For example, predefined control classes such as BUTTON, EDIT, LISTBOX, and COMBOBOX may use these values. Messages in this range should not be sent to other applications unless the applications have been designed to exchange messages and to attach the same meaning to the message numbers.

Message numbers in the third range (0x8000 through 0xBFFF) are available for applications to use as private messages. Messages in this range do not conflict with system messages.

Source

I really don't know enough about this stuff, but wouldn't it be 'more safe' to move the AHK message numbers to the WM_APP range?

[lexikos]

No.

These messages are being "used by an application to send messages within a private window class" (AutoHotkey/AutoHotkeyGUI).

I presume that "meaningful throughout an application" would mean a message that can be posted to a window and handled by the program's message loop, regardless of the window's class, to apply some action to that window. I can't imagine when such a technique would be necessary (why rely on the message loop this way?), but I know when it would fail. There are many cases where the system (or a control) runs a modal message loop, taking control away from the program - for menus, moving/resizing windows, dragging the mouse in a ListView, or handling modal dialogs (though AutoHotkey works around that one). In those cases the program's message loop isn't running, so it can't use "app-wide" messages in that way.

Messages which are sent must be handled by the WindowProc of the window which they are sent to, which basically means that each window must be able to understand that message. Unless you sub-class the window, there'd be no point in sending a custom message to a window of a predefined class. If you have sub-classed the window, I think that a conflict (choosing a message number that already has meaning) is only a problem if someone sends that message for its original purpose.

[just me]

These messages are being "used by an application to send messages within a private window class" (AutoHotkey/AutoHotkeyGUI).

It might sound silly, but obviously some of the messages (e.g. AHK_GUI_ACTION) are touched by the message loops of ListView (and TreeView ) controls. Is "used by an application to send messages within a private window class" still true under this circumstances?

[lexikos]

Yes. They are still being used for the same purpose. These other message loops generally intercept keyboard/mouse messages and dispatch any other messages to the target window's procedure. If they were to intercept messages in the WM_USER range which are targeted at some other window, "can be defined and used by an application to send messages within a private window class" would no longer be true. It would instead be "can only be used to send predefined messages to predefined window classes".

[just me]

Thanks, but the "modal message loops / underlying message pumps" will stay nebulous for me.