To use XFLOGM, just insert XFLOGM.f90. XFLOGM, as DFLOGM, is useful for both Win32 and QuickWin applications. Since Mar 10. 2003, XFLOGM is compatible with DFLOGM.lib from all CVF versions (verified on 5.0D and 6.6B - please contact me if you have problems).

• DLG_BKCOLOR and DLG_COLOR control indices are available static text, group boxes, push buttons, check boxes, and radio buttons. Syntax is:
  
  result = DlgSet/DlgGet(Dlg, idControl, nRGBvalue, DLG_COLOR)
  result = DlgSet/DlgGet(Dlg, idControl, nRGBvalue, DLG_BKCOLOR)
  
  where nRGBvalue is integer in Win32 COLORREF format. nRGBValue can be obtained using:
  - Hex notation #BBGGRR
  - MSFLIB RGBToInteger function
  - DFWIN RGB function
  
  Remarks
  For push buttons, due to Win32 design, these flags affect only "focus rectangle"; for other controls text background and text color are affected, as in picture.
  
  To retreat to the default color values, use -1 as nRGBvalue argument.¹

• DLG_VISIBLE control index shows or hides the control. Syntax is:
  
  result = DlgSet/DlgGet(Dlg, idControl, bVisible, DLG_VISIBLE)
  
  where bVisible is flag which determines visibility of the control.
  
  Remarks
  In version of May 7th 2001, XFLOGM is fixed so that: 
  - DLG_VISIBLE property is correctly initialized according to control's "Visible" style as set up in resource editor; earlier, it was always initialized to .TRUE., causing misbehaviour for controls which are initially hidden.
  - DLG_VISIBLE property is not updated when the dialog is hidden. Before the fix, when the dialog is hidden using ShowWindow or during DlgInitCallback, DlgGet(...DLG_VISIBLE) would always return .FALSE.; now, it returns the last visible state of the control.

• DLG_BITMAP and DLG_ICON¹ control indices are available for push buttons, push-like check boxes, push-like radio buttons and static controls (with "icon" or "bitmap" style). You have to set "Bitmap" or "Icon" style on control's property sheet in order to assign the bitmap to it. Syntax is:
  
  result = DlgSet/DlgGet(Dlg, idControl, hImage, DLG_BITMAP)
  
  where hImage is integer representing handle of the image. You can obtain hBitmap using one of the following Win32 (DFWIN) functions: 
  
  LoadBitmap, LoadImage, CreateBitmapIndirect, CreateBitmap, LoadIcon
  
  Where LoadImage is the most useful, with capability of loading bitmaps and icons both as resource and from file and providing "transparent" effect (LR_LOADMAP3DCOLORS), i.e. light-gray in the original bitmap is replaced with the 3D face color in the actual color scheme. Also, to use 16x16 or other non-default size icons you have to use LoadImage.
  
  Remarks
  LoadImage function is not declared in CVF versions up to 6.0 (to my knowledge) Please refer to comments in Test.f90 about declaring and using LoadImage function, as well as your Win32 help.
  For static controls, hBitmap argument can be also handle of an icon. Icon can be loaded using LoadIcon or LoadImage Win32 function. The static control has to have "icon" style.
  

• DlgSetHelp routine enables you to register your own callback routine when either the user presses the F1 key or uses "context help" dialog feature. DlgSetHelp is similar to DlgSetSub, except that Syntax is:
  
  result = DlgSetHelp(Dlg, HelpCallback)
  
  Where HelpCallback is an EXTERNAL routine which has to be of prototype:
  
  SUBROUTINE HelpCallback(Dlg, idControl, MouseX, MouseY)
  
  where idControl is ID of the control that's been clicked on in the "context help" mode of the dialog, and MouseX and MouseY are mouse coordinates (in screen coordinates).
  
  When CONTEXTID symbol is !DEC$DEFINEd on top of XFLOGM.f90 source (or in Project settings/Fortran/Preprocessor), an additonal argument, idContext, is passed to HelpCallback. HelpCallback must have the following prototype:
  
  SUBROUTINE HelpCallback(Dlg, idControl, idContext, MouseX, MouseY)
  
  idContext is control's help context ID. When used, it can be passed directly to WinHelp function and appropriate popup will appear - no need for SELECT CASE(idControl).
  
  Remarks
  HelpCallback routine typically invokes an user-provided help page from a .hlp file. Please refer to WinHelp Win32 function for details, and Test.f90 sample.
  
  In order to enable context-help feature, you must check both "system menu" and "context help" styles on the dialog's property sheet in resource editor. If so, HelpCallback will be called upon clicking on a control with "question mark" cursor; idControl argument contains ID of the control. HelpCallback should then invoke appropriate popup description using WinHelp function with HELP_CONTEXTPOPUP flag.
  
  On pressing F1 key idControl will contain the ID of the control which has the keyboard focus. However, note that the dialog need not have neither "context help" nor "system menu" style in order to respond to F1 key. If you decide to use a single help page for entire dialog instead of context help popups, simply ignore idControl argument and invoke appropriate page using WinHelp with HELP_CONTEXT flag. <Greg>If CONTEXTID feature is used, by using the HelpID property check box, the resource compiler produces an output Resource.HM file. This resource file may then be used directly in the [MAP] section of the .HPJ project file when compiling the .HLP file, thus saving the process of adding each topic individually. Of course, the .RTF file must then use the ContextID rather than the ControlID when writing each topic. </Greg>
  
  MouseX and MouseY arguments are typically ignored; use them if you want to use a mechanism other than WinHelp, such as tooltips.

• DLG_DRAWITEM control index can be used in conjunction with DlgSetSub for static-controls with "owner-drawn" style. Owner-drawn static controls enable you to draw on its surface at run-time, providing means for displaying bitmaps that change at run-time. Test.f90 sample uses an owner-drawn static control for creation of a simple animation. Syntax is:
  
  result = DlgSetSub(Dlg, idStatic, OwnerDrawCallback, DLG_DRAWITEM)
  
  where idStatic is ID of static control with "owner-draw" style, and OwnerDrawCallback is EXTERNAL callback routine of prototype:
  
  SUBROUTINE OwnerDrawCallback(Dlg, idControl, hDC)
  
  where hDC is integer handle of control's DC. Note that OwnerDrawCallback is of the same prototype as any other routine registered with DlgSetSub. Third argument is used to pass handle of control's DC so that the routine can perform drawing. With other "standard" callbacks this argument is used to indicate type of event that happened on the control; however, since static controls do not respond to user input, this argument is used for other purpose.
  Also, note that "standard" callbacks are invoked when the user performs an action on the control. DLG_DRAWITEM callback is, however, invoked without direct user's action -- whenever the control has to be redrawn. Redrawing occurs whenever a part of the control is revealed, e.g. when another window is moved over the control or when the application comes into foreground. Also, the application itself can force redrawing using Win32 function InvalidateRect. In Test.f90 sample, animation is realised so that a timer is started immediately before DlgModal; the timer function is invoked every 0.1 s and it changes the global radius of the circle and then calls InvalidateRect function, which indirectly triggers the DLG_DRAWITEM callback. For example, if you want the image to change as result of an event in another control in the dialog, simply make a callback routine for that control which calls InvalidateRect. Note that data necessary to perform drawing has to be either exchanged via global variables, or OwnerDrawCallback has to be "intelligent", performing the drawing on the basis of state of other controls in the dialog.
  
  Remarks
  Drawing on control's surface has to be done using Win32 GDI functions. MSFLIB functions such as MoveTo, Rectangle, SetColor are unusable for this purpose. Please refer to "Painting and Drawing" section of Win32 help for detailed description.
  VS resource editor does not enable you to specify "owner drawn" style for static controls from the IDE (on the control's property sheet). To workaround this, insert a "picture" control of type "black frame". After saving resource, open the .rc file in a text editor (from VS IDE, in File/Open dialog, specify "Text" in "Open as" dropdown) and replace "SS_BLACKFRAME" with "SS_OWNERDRAW" for that control. Make sure that control ID is other than IDC_STATIC.

• You can specify handle of the dialog's owner window as second optional argument to DlgModal, which is useful for Win32 applications.

• A change in behaviour of dialogs with "center" style is introduced in XFLOGM. By default, dialogs with this style are displayed in center of the screen. More logical behaviour is that they are centered relative to its owner-window (as specified in above-mentioned change in DlgModal). In QuickWin applications,  you can obtain handle of dialog's parent window using GetHWNDQQ MSFLIB function.

• With original DFLOGM, tabbed dialogs had a flaw that the tab key did not work correctly to navigate between items in child dialogs. The cause of the problem was that it required child dialogs to be children of Tab control. Tab control gets in the way of how IsDialogMessage handles special keys (Tab, Enter, Cancel). 
  
  A far better setup is to set child dialogs to have main dialog as parent. XFLOGM now allows you to specify
  
  result = DlgModeless(ChildDlg, SW_HIDE, MainDlg%hWnd)
  
  ("old" style is still supported). Also, don't forget that child dialogs have to have "Child" and "Control" styles for tab key to work correctly.²

• Subroutine DlgSetTitle(Dlg, title) sets the caption of the dialog. ³

¹) As of Dec 11 2001.

²) As of Apr 11 2002.

³) As of Mar 10 2003.