Back to Contents


Frequently Asked Questions

This page contains questions frequently asked when migrating applications from BDL V3 to Genero BDL.

FAQ001: When using Genero, why do I have a different display than with BDL V3?
FAQ002: Why does an empty window always appear?
FAQ003: Why do some COMMAND KEY buttons no longer appear?
FAQ004: Why aren't the elements of my forms aligned properly?
FAQ005: Why doesn't the ESC key validate my input?
FAQ006: Why doesn't the CTRL-C key cancel my input?
FAQ007: Why do the gui.* FGLPROFILE entries have no effect?
FAQ008: Why do I get a link error when using the FGL_GETKEY() function?


FAQ001: When using Genero, why do I have a different display than with BDL V3?

Explanation:

Genero introduces major Graphical User Interface enhancements that sometimes require code modification. With BDL V3, application windows created with the OPEN WINDOW instruction were displayed as static boxes in the main graphical window. In the new GUI mode of Genero, application windows are displayed as independent, resizable graphical windows.

Links: Dynamic User Interface, Windows, Application class.


FAQ002: Why does an empty window always appear?

Description:

An additional empty window appears when I explicitly create a window with OPEN WINDOW (following the new window management rules).

01 MAIN
02   OPEN WINDOW w1 AT 1,1 WITH FORM "form1"
03   MENU "Example"
04    COMMAND "Exit"
05     EXIT MENU
06   END MENU
07   CLOSE WINDOW w1
08 END MAIN

Explanation:

In the new standard graphical mode, all Windows are displayed as real front-end windows, including the default SCREEN Window. When an application starts, the runtime system creates this default SCREEN Window, as in version 3. This is required because some applications use the SCREEN Window to display forms (they do not use the OPEN WINDOW instruction to create new windows). So, to facilitate V3 to Genero migration, the runtime system must keep the default SCREEN window creation; otherwise, existing applications would fail if their code was not modified.

Solution:

Simply issue a CLOSE WINDOW SCREEN at the beginning of the program, to close the default window created by the runtime system. You typically do this in an initialization function that could be shared by several program sources.

Example:

01 MAIN
02   CALL myInit()
03   OPEN WINDOW w1 AT 1,1 WITH FORM "form1"
03   MENU "Example"
04    COMMAND "Exit"
05     EXIT MENU
06   END MENU
07   CLOSE WINDOW w1
08 END MAIN
09 
10 FUNCTION myInit()
11   CLOSE WINDOW SCREEN
12 END FUNCTION

FAQ003: Why do some COMMAND KEY buttons no longer appear?

Description:

When creating a MENU with COMMAND KEY(keyname) "option" clause, the button for keyname is no longer displayed:

01 MAIN
02   MENU "Example"
03     COMMAND "First"
04       EXIT PROGRAM
05     COMMAND KEY (F5) "Second"
06       EXIT PROGRAM
07     COMMAND KEY (F6) -- Third is a hidden option
08       EXIT PROGRAM
09   END MENU
10 END MAIN

Explanation:

In BDL Version 3, when using the MENU instruction, several buttons are displayed for each clause of the type COMMAND KEY(keyname) "option": one for the menu option, and others for each associated key.

When using Genero, a named MENU option can only be associated to one accelerator key. As there is no need to display different buttons for a unique application function, the buttons of associated keys are no longer displayed (F5 in our example), since there is already a button created for the named menu option. The so called "hidden menu options" created by a COMMAND KEY(keyname) clause (F6 in our example) are not displayed as long as you do not associate a label, for example with the FGL_SETKEYLABEL() function.


FAQ004: Why aren't the elements of my forms aligned properly?

Description:

In my forms, I used to align labels and fields by character, for typical terminal display. But now, when using the new LAYOUT section, some elements are not aligned as expected. In the following example, the beginning of the field f001 is expected in the column near the end of the digit-based text of the first line, but the field is actually displayed just after the label "Name:":

01 DATABASE FORMONLY
02
03 LAYOUT
04   GRID {
05   01234567890123456789
06    Name:             [f001       ]
07   }
08   END
09 END
10
11 ATTRIBUTES
12 f001 = formonly.field1 TYPE CHAR;
13 END

Explanation:

By default, BDL Genero displays form elements with proportional fonts, using layout managers to align these elements inside the window. In some cases, this requires a review of the content of form screens when using the new layout management, because it is based on new alignment rules which are more abstract and automatic than the character-based grids in Version 3.

In most cases, the form compiler is able to analyze the layout section of form specification files in order to produce an acceptable presentation, but sometimes you will have to touch the form files to give hints for the alignment of elements.

Solution:

In the above example, the field f001 is aligned according to the label appearing on the same line. By adding one space before the field position, the form compiler will understand that the field must be aligned to the text in the first line:

01 DATABASE FORMONLY
02
03 LAYOUT
04  GRID {
05  01234567890123456789
06   Name:              [f001       ]
07  }
08  END
09 END
10
11 ATTRIBUTES
12 f001 = formonly.field1 TYPE CHAR;
13 END

In the next example, the fields are automatically aligned to the text in the first line:

01 DATABASE FORMONLY
02
03 LAYOUT
04  GRID {
05                 First         Last
06    Name:        [f001      ]  [f002       ]
07  }
08  END
09 END
10
11 ATTRIBUTES
12 f001 = formonly.field1 TYPE CHAR;
13 f002 = formonly.field2 TYPE CHAR;
14 END

FAQ005: Why doesn't the ESC key validate my input?

Description:

The traditional 4GL ESC key does not validate an INPUT, but cancels it instead!

Explanation:

To follow front end platform standards (like Microsoft Windows for example), Genero must reserve the ESC key as the standard key to cancel the current interactive statement.

Solution:

You can change the accelerator keys for the 'accept' action with Action Defaults.


FAQ006: Why doesn't the CTRL-C key cancel my input?

Description:

The traditional 4GL CTRL-C key does not cancel an INPUT.

Explanation:

To follow front end platform standards (like Microsoft Windows for example), Genero BDL must reserve the CTRL-C key as the standard key to copy the current selected text to the clipboard, for cut and paste.

Solution:

You can change the accelerator keys for the 'cancel' action with Action Defaults.


FAQ007: Why do the gui.* FGLPROFILE entries have no effect?

Description:

The gui.* and some other FGLPROFILE entries related to graphics no longer have effect.

Explanation:

These entries are related to the old user interface. They are no longer supported. In version 3, the gui.* entries were interpreted by the front end. As the user interface has completely been re-designed, the gui.* entries have been removed, too .

Solution:

Review the definition of these entries and use the new possibilities of the Dynamic User Interface.

Entry Replacement
menu.Style None, no longer needed.
key.key-name.order None, no longer needed.
Menu.defKeys None, no longer needed.
InputArray.defKeys None, no longer needed.
DisplayArray.defKeys None, no longer needed.
Input.defKeys None, no longer needed.
Construct.defKeys None, no longer needed.
Prompt.defKeys None, no longer needed.
Sleep.defKeys None, no longer needed.
GetKey.defKeys None, no longer needed.
gui.local.edit.* None, no longer needed.
gui.preventClose.message None, cancel action is sent when the user closes a window.
gui.chartable None, no longer needed.
gui.whatch.delay None.
gui.useOOB.interrupt None.
gui.containerType None.
gui.containerName None.
gui.mdi.* None.
gui.screen.clientPositioning None.
gui.screen.size.* None.
gui.screen.x None.
gui.screen.incrx None.
gui.screen.y None.
gui.screen.incry None.
gui.screen.withwm None.
gui.workSpaceFrame.noList None.
gui.workSpaceFrame.screenArray.optimalStretch None.
gui.workSpaceFrame.screenArray.compressed None.
gui.controlFrame.visible None.
gui.controlFrame.position None.
gui.controlFrame.scrollVisible None.
gui.controlFrame.scroll.* None.
gui.bubbleHelp.* None, front end specific.
gui.directory.images None, front end specific.
gui.toolbar.dir None, front end specific.
gui.toolbar.* The new toolbar definition.
gui.menu.* None.
gui.menuButton.* None.
gui.button.* None.
gui.empty.button.visible None.
gui.keyButton.* None, front end specific.
gui.key.add_function None.
gui.key.interrupt None.
gui.key.doubleClick.left None.
gui.key.click.right None.
gui.key.num.translate None.
gui.key.copy None, front end specific.
gui.key.paste None, front end specific.
gui.key.cut None, front end specific.
gui.form.foldertab.* None.
gui.key.forldertab.input.sendNextField None.
gui.key.foldertab.num.selection None.
gui.mswindow.button None, front end specific.
gui.fieldButton.style None, front end specific.
gui.BMPButton.style None, front end specific.
gui.key.radiocheck.invokeexit None.
gui.entry.style None, front end specific.
gui.interaction.inputarray.usehighlightcolor None, front end specific.
gui.mswindow.scrollbar None, front end specific.
gui.scrollbar.expandwindow None, front end specific.
gui.statusbar.* None, front end specific.
gui.display.* None.
gui.user.font.choice None.

FAQ008: Why do I get a link error when using the FGL_GETKEY() function?

Description:

This function is no longer supported; it has been removed from the language.

Explanation:

That function waited for a key-press from the user, but this kind of interaction does not fit into the new user interface protocol.

Solution:

Review the program and use standard interactive instructions to manage the interaction with the user.
See the Dynamic User Interface concept.