Pages

05 February 2012

The Dialog command used in a GLL editor extension is quite different than the Dialog in a normal GB32 application. How is that possible?

When one or more GLLs is loaded in memory, the IDE assigns the compiled GLL an array with pointers to the GB32 library functions in the runtime DLL (or Ocx). This is the same array with pointers each application gets when it is loaded. This way a call to a library function like Left$(), Dialog, or OpenW, etc, will reference the appropriate function in the runtime. When the GLL is loaded some of these pointers are replaced by addresses of functions inside the IDE executable. This way when the GLL invokes a dialog related function it will call the function inside the IDE, rather than in the runtime. All the dialog box related functions and commands are replaced. Examples are the Control command and the names of standard and common controls. You'll find an overview of the valid GB32 dialog box related statements and functions in the help file.

The GB32 dialog box related statements and functions are GfaBasic for Windows 16-bit-compatible. However, the window styles specified in the Dialog # command may come as a surprise. When you omit the style GB32 uses a default window style. GB32 processes as follows:

The system creates the window (dialog box) with the WS_EX_TOPMOST style using CreateWindowEx(). The dialog has no owner or parent. It is modeless because it exist parallel to the Gfa_hWnd IDE window.
The WS_EX_TOPMOST style does not prevent the user from accessing other windows on the desktop.
This gives you the tools puzzle the appearance of GLL dialog box and might explain its unexpected visual style.