FGL_WINMESSAGE, FGL_WINQUESTION

FGL_WINMESSAGE and FGL_WINQUESTION are not built-into the runtime system, but are examples of utility functions that we provide.  As such if you look in $FGLDIR/src/fgldialog.4gl you will find that these functions are implemented by 4gl code and are compiled into $FGLDIR/lib/fgldialog.42m

This means that if you are not happy with these utility functions, you can look at the source and use these as inspiration to write your own library functions.  For example you may view …

FUNCTION my_winmessage(title STRING, text STRING, icon STRING)
    MENU title ATTRIBUTES(STYLE="dialog", COMMENT=text, IMAGE=icon)
        ON ACTION accept
            EXIT MENU
    END MENU
END FUNCTION

… as an improvement on FGL_WINMESSAGE as you won’t have the restriction of …

Supported names for the icon parameter are: information, exclamation, question, stop

… that FGL_WINMESSAGE has.

What you might not realise is that you can override the utility function if you are happy accepting the same function signature.  So if you write a little test program …

MAIN
    CALL FGL_WINMESSAGE("Information", "My very own fgl_winmessage","smiley")
END MAIN

FUNCTION FGL_WINMESSAGE(title STRING, text STRING, icon STRING)
    MENU title ATTRIBUTES(STYLE="dialog", COMMENT=text, IMAGE=icon)
       ON ACTION accept
            EXIT MENU
    END MENU
END FUNCTION

… you will see that this is used instead of the built-in utility function (you can tell as smiley is not supported by the built-in FGL_WINMESSAGE).    I’ll let you explore this concept further by moving the function into a seperate 4gl and verifying it it still used first wether using linking or IMPORT FGL.

( Note: Personally I’d avoid this overriding concept as it may get confusing if your version of FGL_WINMESSAGE differs too much from the documented FGL_WINMESSAGE, and I think it is better to leave FGL_ as the prefix as being something written by us, and for you to write a function using your own naming convention)

If using code from $FGLDIR/src/fgldialog.4gl as inspiration,  you will see that technically FGL_WINMESSAGE and FGL_WINQUESTION are not MENU STYLE=”dialog” but that the style is set …

LET styleToUse = "winmsg" , fgl_winDialogDirection

… this undocumented style prefixed “winmsg” is actually a signal to the front-end client to use a built-in system dialog.   In the case of the GDC, this built-in system dialog is modal to the GDC and so blocks all the other GDC windows.  This is why you might find if using FGL_WINMESSAGE that you can’t do anything in a Genero application window for program B because program A has an active FGL_WINMESSAGE dialog that is blocking.

If I was to summarise why users may override FGL_WINMESSAGE, FGL_WINQUESTION or to write their own library equivalents, the reasons will  include …

• to avoid this blocking behaviour by using STYLE=”dialog” instead
• to avoid the narrow range of icons and options
• application localization vs system localization
• to standardize their dialogs to some standard text

… please don’t feel that you are restricted to what utility functions such as FGL_WINMESSAGE, FGL_WINQUESTION provide.  Be aware that you can override them, or use their source as inspiration for your own family of library functions doing what you want.