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 and ultimately improve user productivity with Genero.
A modern software application invariably has to be broken down into separate executables. Generally, there are many discrete operations and it would be impractical to have them all handled by just one executable.
In 4GL it’s only possible to have one interactive program visible and usable at a time. From the main menu (for instance) you can execute the following statement –
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, the application user cannot switch back to the other program to do something else.
It’s possible to add ‘WITHOUT WAITING’ to the RUN statement which will have concurrent processes running, but that will create a background process which cannot be accessed or used by the application user. It was mainly used for tasks like running a 4GL report in the background.
So the user is creating an order, for instance, and needs to update something else whilst doing that, the only options are to either: (a) terminate the order program and then choose the other; or (b) start up the whole application again from another terminal 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 it’s now possible to have another interactive program running concurrently. Using the following code will allow you to have multiple foreground and, therefore, interactive programs running simultaneously.
And because these programs are completely discrete processes you can have as many of each running as you want, 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 ‘Schedule’ are the main windows of 3 separate programs, invoked from the top menu. These are concurrent, and the user can switch to another at any time, without interrupting that which is currently in progress e.g. an Input statement.
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 which container is its parent. If you don’t do that for the child program it will have its own window.
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.
As a developer, you 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 isn’t 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 which 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 your 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’ –
Genero have upgraded 4GL to a GUI language with full modern functionality, but still with the original language structure and syntax, so it can be very straightforward to modernise some aspects of your legacy 4GL application, and significantly improve user productivity with Genero.
The code fix suggested 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.