WM_TOMAHAWK Documentation

Contents

The WM_TOMAHAWK Message

Tomahawk defines a Windows message called WM_TOMAHAWK, in keeping with the naming conventions of such things. It is general purpose, using a subcode for different meanings. Anything the library needs to do that requires a special message can use this one.

The message identifier is dynamically allocated from Windows, using RegisterWindowMessage ("WM_TOMAHAWK"). You don’t know what the number is, and it may vary from run to run. But, it will be the same for the life of the program, and the same across all programs in the same Window Session.

To obtain the message identifier, use the static memer get_TOMAHAWK_id in the file Tomahawk\MSG\WM_TOMAHAWK.h. The full name is seen in the example:

const unsigned WM_TOMAHAWK= ::tomahawk::MSG::WM_TOMAHAWK_msg::get_TOMAHAWK_id();

The WM_TOMAHAWK_msg Structure

The WM_TOMAHAWK_msg structure is similar to the WM_ ..._msg structures defined for the normal Windows messages. However, because the message’s id code is not known at compile time, there are a couple differences:

The constant member message_constant is defined for consistancy with the other message structures. However, it is not known at compile time, and is computed at static construction time when the program is loaded. Because the order of initialization of the DLLs making up a program is undefined, you should not count on Tomahawk’s static constructors to be called already when executing the code belonging to a static constructor in a DLL. (In the main EXE code, you know all DLLs have been initialized first.)

The function get_TOMAHAWK_id will always work, though.

The other difference you may notice is that using the WM_TOMAHAWK struct will incur a dependancy on the Tomahawk DLL, while none of the other WM_..._msg structs do since they are entirely inline. However, if you are using the WM_TOMAHAWK message you are probably using other features of the library anyway.

Subcodes

The pre_translate_message subcode

The pre-translate message is part of a convention that allows windows to define their own pre-translation step. Instead of a message pump needing to know about the windows it is servicing and call IsDialog for every dialog box and TranslateAccelerator for top-level windows that use accelerator tables, this message is used so that the message routing system can let the window define its own work, in the same way as any other message is handled by windows.

The proper use can be seen in the simple_message_pump::pre_translate function. The other end—code that receives the message and does any pre-translation—can be seen in the message_tap::pre_translate_message function.

The reset_minister subcode

The mouse_button subcode