Event messages used by WinDom

WM_DESTROY

This message means the targeted window should be destroyed. WinDom makes the distinction between WM_CLOSED that means the window should be closed on the screen but stays in memory and this message that means :

• data attached to this window should be saave then destroy

• the window should be close and remove from the memory

Note: on singleTOS, this message is sent when a user clicks on the closer window widget with the shift key pressed.

evnt.buff[0] = WM_DESTROY
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle

WM_BOTTOMED

This message is standard from AES 4.0. It means that a window should be sent in the background (at the bottom of the window liste). This message is emulated by WinDom if the system does not support it. If the system does not support the bottomer widget, a window can be sent to background by shift clicking the widget mover bar.

evnt.buff[0] = WM_BOTTOMED
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle

WM_ICONIFY, WM_UNICONIFY, WM_ALLICONIFY

These message are standards from AES 4.1 . However, WinDom emulates them (if there are not available in the system) to handle the window iconification.

A window should be iconified ...

evnt.buff[0] = WM_ICONIFY
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle evnt.buff[4-7] = position and size of the icon window

A window should be uniconified ...

evnt.buff[0] = WM_UNICONIFY
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle evnt.buff[4-7] = position and size of the uniconified window

All windows should be iconified ...

evnt.buff[0] = WM_ALLICONIFY
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle evnt.buff[4-7] = position and size of the main icon window

WM_FORM

These message means that a selectable object is selected (with the mouse or the keyboard) in a window formular.

evnt.buff[0] = WM_FORM
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle
evnt.buff[4] = selected object index
evnt.buff[5] = keyboard state (see evnt_button())

MN_SELECTED

The message means a menu item has been selected from the desktop or from a window.

evnt.buff[0] = MN_SELECTED
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = title menu index
evnt.buff[4] = item menu index
evnt.buff[5-6] = address of the menu root object
evnt.buff[7] = index of object parent's selected item

Values of word 5,6 and 7 are an extension of AES 3.3 (this feature needs to be tested with appl_getinfo()). However, WinDom emulates it for all TOS version.

When a windom menu is selected, it is not easy to retrieve the window handle hosting the menu : you have to walk into the windows chained list and test the value of menu.root field of the WINDOW structure.

WM_TOOLBAR

These message means that a selectable object is selected (with the mouse or the keyboard) in a window toolbar.

evnt.buff[0] = WM_TOOLBAR
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = window handle
evnt.buff[4] = selected object index
evnt.buff[5] = keyboard state (see evnt_button())

AP_LOADCONF

When EvntWindom() received this message, the WinDom configuration file is reloaded. This message allows special WinDom application such as WinConf to parametrise in real time the Look'n Feel aspects of WinDom. It is a good idea to handle this message if you use the WinDom configuration file (see Conf library) to store your application parameters.

evnt.buff[0] = AP_LOADCONF
evnt.buff[1] = application id

AP_BUTTON

When EvntWindom() receives this message, a MU_BUTTON event is created. This message is used to simulated a MU_BUTTON event.

evnt.buff[0] = AP_BUTTON
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = coordinate x of the mouse
evnt.buff[4] = coordinate y of the mouse
evnt.buff[5] = mouse button state (see evnt_button())
evnt.buff[6] = keyboard state (see evnt_button())

AP_KEYBD

When EvntWindom() receives this message, a MU_KEYBD event is created. This message is used to simulated a MU_KEYBD event.

evnt.buff[0] = AP_KEYBD
evnt.buff[1] = application id
evnt.buff[2] = 0
evnt.buff[3] = scancode of the key hited
evnt.buff[4] = keyboard state (see evnt_button())

WM_UPLINED, WM_DNLINED, WM_UPPAGED, ...

These messages are strictly equivalent to WM_ARROWED messages (WA_UPLINED, WA_DNLINED, WA_UPPAGED). As these message are sub-mode of WM_ARROWED, they cannot be binded directly with EvntAttach(). It is now possible with the new messages WM_UPLINED ...

evnt.buff[0] = message
evnt.buff[1] = application id
evnt.buff[2] = 0

WM_PREREDRAW

This function attached to this message is called one and ony one time per WM_REDRAW event. A WM_REDRAW function can be called several time for a same event because because EvntWindom() calls the binded function for each rectangle of the AES rectangle list (it is the AES method to draw windows partially occlused). In some case, this WinDom feature can be an handicap, specially if you want perform one action per WM_REDRAW. In this case, you can catch the WM_PREREDRAW event which it call only one time (by EvntWindom()) for each WM_REDRAW event.

Notice, if you catch the WM_PREREDRAW event instead of the WM_REDRAW message, you can control complety the event and you disable the WinDom handling of redraw event (clipping on each AES rectangle).