Executing programs

Prerequisites before executing a program

Make sure that all required environment variables are properly defined, such as FGLPROFILE, FGLGUI, FGLSERVER, FGLLDPATH, LANG/LC_ALL.

To display program forms in graphical mode, the GUI front-end must run on the computer defined by FGLSERVER, and all network security components (i.e. firewalls) must allow TCP connections on the port defined by this environment variable.

Verify the database client environment settings, and check that the database server is running and can be accessed, for example by using a database vendor specific tool to execute SQL commands.

Starting a program from the command line on the server

A program can be executed with the fglrun tool from the server command line:

fglrun myprogram

This method is typically used in development context. After compiling the programs and forms, for example with the make utility, execute the programs with fglrun.

Note: The file extension (.42m or .42r) can be omitted. If no file extension is specified, fglrun will try to load progname.42r, then progname.42m.

Executing sub-programs from a parent program with RUN

Sub-programs can be executed from the main program with the RUN instruction. There can be limitations, according to the platform where the parent program executes.

Starting a program from the front-end

It is also possible to start programs on the application server from the platform where the front-end resides.

This is actually the typical way to start applications in a production environment.

For a desktop front-end (GDC) application, define application shortcuts and use rlogin/ssh network protocols to start programs on the server or by using HTTP through a web server (GAS).
For a web-browser application (GWC), configure the application server (GAS) to run applications from an URL.
For a mobile device application (GMI/GMA), in a configuration where the programs run on a GAS application server, use the "runOnServer" front call, to start a program from the GAS.

Starting programs on a mobile device

After deploying program files on a mobile device, it can be executed as a local application, typically with a tap on the application icon.

For a GMA (Android™) application, program files and GMA must be bundled together in an .apk Android package to be deployed. For more details, see Deploying mobile apps on Android devices.
For a GMI (iOS) application, program files and GMI must be bundled together in an .ipa package to be deployed. For more details, see Deploying mobile apps on iOS devices.
To start programs on an application server from a small embedded mobile application (starter), use the runOnServer front call. For more details, see Running mobile apps on an application server.

Controlling Android app states (GMA)

On Android devices, an app can switch between foreground to background states.

The Android system can decide to stop an app in background state, for example when resources are required for other apps.

Genero programs running on servers are typically not prepared to be stopped at any time: Except in case of major failure, it's the program which decides when it terminates. On mobile devices, Android can decide to stop the app when it is in background state.

By default, when the app goes to background state, a notification is shown by GMA, to keep the app in foreground state, and avoid Android to stop the app. The notification disappears, when the app returns to foreground state.

Use the androidKeepForeground style attribute to control the way the GMA forces Android to keep your app alive: Set this attribute to "no" if your app can be stopped by Android, when it is in background state. When this style attribute is set to "no", GMA will not displaye a notification, when the app switches to background mode.

Important: When using androidKeepForeground=no, Android may stop the app at any time: Make sure that the code is ready for this case.

For more details, see UserInterface style attributes.

Common app directories on mobile platforms

On mobile devices, you can use the following APIs to get common directories:

base.Application.getProgramDir returns the directory path where the main .42m is located. Consider this location read-only and safe (no other app can access it).
os.Path.pwd returns the path to the current working directory. When a mobile application is started, the GMA and the GMI set the working directory to the default application directory. Consider this location read-write and safe (no other app can access it).
The front call standard.feInfo/dataDirectory returns the front-end side temporary directory. Storage on this directory may be erased by the OS. On an embedded mobile application, as the runtime and the front-end run on the same system, the program can use this front call to retrieve a temporary directory and use the path to store temporary files. Consider this location read-write and unsafe. Applications executed remotely through a runOnServer front call, can use the sandboxRunOnServer directory under the directory returned by the feInfo/dataDirectory front call, to exchange files with the embedded application.