Call back procedures for window messages of a Form.
Sub Form_MessageProc(hWnd%, Mess%, wParam%, lParam%, retval%, ValidRet?)
Sub Form_DDEWndProc(hWnd%, Mess%, wParam%, lParam%, retval%, ValidRet?)
With the MessageProc event sub you can actually filter or influence the behaviour of the form/window procedure for the Form window class. The MessageProc is called before gb32 handles the message itself. The sub obtains six parameters. The first four are the same as defined for any Windows API window procedure: hWnd%, Mess%, wParam%, and lParam%. Every message, whether it is obtained from the message queue (the posted messages) or by a direct call from any other source (SendMessage), is handled in the window procedure. The hWnd parameter is the window to which the message is sent (because the MessageProc is attached to a Form, we already know the objects name); the Mess parameter is the message number-which is usually a constant such as WM_ACTIVATEAPP or WM_PAINT; the wParam and lParam parameters differ for each message, as does the return value; you must look up the specific message to see what they mean - often, wParam and the return value is ignored, but not always.
The MessageProc event sub has two additional parameters (ByRef) that allow you to return a value. For instance, when you don't want GB32 to handle a certain message you can set the ValidRet? variable to True and provide a return value by setting RetVal%. What value RetVal must have is defined in the Windows API SDK. It often says something like: "If you handle this message return zero (or..)".
The DDEWndProc is a call back procedure as well. It is invoked from inside the window procedure for the form/window. However, the DDEWndProc is only invoked for DDE messages: WM_DDE_ACK, WM_DDE_POKE, WM_DDE_EXECUTE, WM_DDE_DATA, WM_DDE_ADVISE, WM_DDE_UNADVISE, or WM_DDE_INITIATE, and WM_DDE_REQUEST. The RetVal% and ValidRet? variables are used to return values.
Now let us look at an example. Suppose you want to store the window coordinates of OpenW #1 in the register so the application can use these value to open at the same place. In GB32 you could handle the sub events ReSize and Moved to store the coordinates. As an alternative, you could use MessageProc and handle the WM_EXITSIZEMOVE message.
Sub Win_1_MessageProc(hWnd%, Mess%, wParam%, lParam%, Retval%, ValidRet?)
Local Int x, y, w, h
Switch Mess
Case WM_EXITSIZEMOVE
GetWinRect hwnd, x, y, w, h
SaveSetting "MyComp", "ThisApp", "Position", Mkl$(x, y, w, h)
ValiRet? = True
RetVal = 0
EndSwitch
EndSub
The MessageProc event sub actually _is_ the subclass procedure for the GB32 OpenW, Form, and Dialog windows. Subclassing is a built-in feature of GFA-BASIC 32. The OCX Form is perfectly suited to write custom controls.
When OpenW uses a number > 31, the window is accessed using Form(n) and the event subs as Form_event(index%, …).
The MessageProc and DDEWndProc event subs do not work for Ocx Forms in an array or any Windows whose ID number is greater than 31; the relevant code is missing from the ocx and it is unlikely that this bug will ever be fixed.
{Created by Sjouke Hamstra; Last updated: 01/08/2022 by James Gaite; Other Contributors: Jean-Marie Melanson}