Running multiple separate executables in one application.


Historically data input applications only allowed a user to access one part of the application at any one time. If a user needed to access another part of the application, for example to view customer details whilst updating an order, he or she would need to stop what they were doing and navigate to another part of the same application. As applications have grown larger and more complex this becomes a big user productivity drain.

This article describes how to solve this problem elegantly and simply in Genero, by allowing multiple modules of the same application to run concurrently in a single window.


Your application invariably has to be broken down into separate executables, as you has many discrete operations and it would be impractical to have them all handled by just one executable.

In 4GL you can only have one interactive program visible and usable at a time. From the main menu (for instance) you would execute the following statement –

RUN “./invoice.4ge”

This statement would cause execution of the current 4GL program to pause, and it would only resume when the process invoked by the RUN command terminates. So whilst ‘invoice.4ge’ is running one cannot switch back to the other program to do something else.

You can add ‘WITHOUT WAITING’ to the RUN statement which will have concurrent processes running, but that will create a background process which means of course that you can’t do or see anything with it. It was mainly used for tasks like running a 4GL report in the background.

So if you are creating an order, for instance, and need to update something else whilst doing that, the only options are to either terminate the order program and then choose the other, or start up the whole application again from another telnet session and select the program in question.

In Genero this has been changed, ‘RUN . . . . WITHOUT WAITING’ no longer runs that as a background process, so you can have another interactive program running concurrently. Using the following code will allow you to have multiple foreground, and therefore interactive, programs running simultaneously.

COMMAND   "order"
        RUN "fglrun m_order.4ge" WITHOUT WAITING

COMMAND   "maint"
        RUN "fglrun m_maint.4ge" WITHOUT WAITING

COMMAND   "model"
        RUN "fglrun m_model.4ge" WITHOUT WAITING

And because these programs are completely discrete processes you can have as many of each running as you wish, so you can create, edit, look at (or whatever) multiple orders at the same, for instance.

Display options for concurrent processes.

By default the screen for each program that is executed will be in its own window, but in Genero it can be in a tab in the main application’s window. In the screenshot below the three tabs ‘Quotation’, ‘Stock Cards’ and ‘Schedules’ are the main windows of 3 separate programs, invoked from the top menu.

These are concurrent, and you can switch to another at any time, without interrupting that which is currently in progress e.g. an INPUT statement in ‘Schedules’ as below.

Substitution: Image 1

There’s only a few lines of code required – in the ‘parent’ program set the interface type to ‘container’ and give it a name, and in the ‘child’ programs set the interface type to ‘child’ and specify the name of its parent container. If you don’t do that for the child program it will have its own window.

Parent program

        LET lc_container = "cont_main"
    CALL ui.Interface.setName(lc_container CLIPPED)
    CALL ui.Interface.setType("container")

Child program

        CALL ui.Interface.setType("child")
    CALL ui.Interface.setContainer("cont_main")

This needs to be done at the beginning of the program, before any interactive instruction e.g. the MENU command in the parent program, or OPEN WINDOW in the child program.

One can mix and match - some programs can have their own windows, and some can have a tab in the ‘main’ window. And you could code a program such that depending on what parameters are passed across it will either be in a container or its own window (for the latter simply don’t execute the statements in the ‘Child Program’ example above). This will not affect the code for displaying the form, the input statements etc. as the code at that level is not affected by this. So you could have one menu entry to have ‘maint’ in a tab, and another to have it in a separate window.

You cannot create a tree structure i.e. a container has a child which in turn has a child, as the child’s interface type has to be ‘child’, rather than ‘container’, but a program started from a ‘child’ can appear in a tab in the main window. If a program started from the main window has its own window then that can be a container; a program called from there, the main window or any other program can appear in that container, or any other, as long as the specified container does already exist. Odd scenario though!

Another option for ‘container’ type windows is whether or not the ‘child’ windows appear in a tab. In Genero there are ‘style’ files, which you can use to set many default attributes for windows. At the start of a program you can load the style file of one’s choice, and when opening a window specify which style defined in that file to use. One such attribute is ‘tabbedcontainer’ – if set to ‘yes’ for the window specified as a container then each time another program opens a ‘child’ window for that container it will appear in a new tab. But if the attribute is set to ‘no’ the child windows will simply appear in the container, and can be dragged around etc.

Follow this link and search for ‘window container’ –


As with other functionality Genero have added to 4GL, this can significantly improve user productivity, as many functions can be running concurrently. For instance, when confirming a customer’s order, you can view your stock levels and production schedule simultaneously, instead of having to close the current window in order to open another.


The above is provided "as is" without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.