The menu action functions FORMCALL(), MENUCALL() and CHECKMARK() are provided for your convenience when prototyping your applications. However, there are some drawbacks to using these functions in your finished application, particularly if your application is very large.
MENUCALL() and FORMCALL() both assume that the form they need to process is already in memory. If you use MENUCALL() and FORMCALL() to process sub-menus and data forms, you must have all these sub-menus and data forms in memory before you begin processing the top-level menu. This can cause two problems in large applications.
First, if your application is large, and especially if you have a large menu tree in the application, your application may run out of memory, either when you are trying to define forms or read them from the Designer library, or later on in your application when you need to allocate memory for some other reason.
Second, in order to get all the forms and menus into memory before processing the top-level menu, you must read all the forms in from the Designer library, or make all the fm_def() and fld_def() calls, before displaying the top-level menu. This can take an unacceptable length of time for large applications. Your user may be unhappy with a long delay when starting the application.
Third, if you use FORMCALL() and MENUCALL(), you cannot get control to perform other actions before or after the form or menu is processed.
For these reasons, we recommend that you consider writing your own action functions instead of using FORMCALL() and MENUCALL().
CHECKMARK() has limited use because it only toggles the checkmark for the menu field. If you need to perform any other actions based on the status of the checkmark, you may need to write your own action function that performs those actions and then toggles the checkmark status for the field. For more information about changing the checkmark status of a menu field, see Chapter 21, "Changing the Appearance of Menus."
