GBC 4.01
Installing and upgrading
Download packages Upgrading
Compatibility with FGLGWS and GAS Customization migration Deploy runtime on GAS Upgrade to GAS 3.20 Upgrade to GAS 3.10
Migrating GDC to GBC
Limitations Evaluate Migration tips
Migrating GWC-HTML5 to GBC
Evaluate

While most Genero Desktop Client (GDC) features are supported by the Genero Browser Client (GBC), some features are unsupported or only partially supported (see Limitations). With these limitations in mind, this topic shows you how to evaluate the way your application will run on GBC.

One method of evaluating is to run the application and see what happens! If you encounter an issue, you need to determine if this is a limitation, a customization, or a bug. See Migration tips for help in solving migration issues.

Rendering limitations

An application can display on different display sizes and devices, but an exact pixel-by-pixel match with GDC cannot be expected.

For applications rendering in the GDC, you may have sized your application forms to fit in a sized area of a monitor. There is no guarantee that the application will render inside a browser tab at the exact same size. To ensure that your application works for your target devices, review your application forms.

Pop-up windows

The GBC is a Web client and not a fully-implemented windows manager. It displays a maximum of two windows at one time. It always displays the topmost normal (non-modal) window; if a modal window is opened, it is displayed over the non-modal window. This is the equivalent of running the GDC with every non-modal window maximized.

NOTE You do have access to stacked windows in the GBC through the sidebar, but only non-modal windows are accessible.

If window B is opened on top of window A, and window A has useful information, consider opening window B as modal. This can be accomplished by referencing the default.4st window style and setting the attribute STYLE="dialog" in the Genero BDL code:

OPEN window msg WITH FORM "MyWindowB" ATTRIBUTES (STYLE="dialog")

Window B then displays as a pop-up window.

An alternative is to consolidate window A and window B together as one window.

If you already have pop-up windows in your GDC application, and you want to have consistency between windows in GDC and GBC, set the windowType style attribute to modal in the Genero style for Window.dialog (in the default.4st).

NOTE: Any presentation style (4st) element bound to a window may contain the windowType attribute.

Excerpt from $FGLDIR/lib/default.4st

<Style name="Window.dialog">
  <StyleAttribute name="windowType" value="modal" />
  <StyleAttribute name="sizable" value="no" />
  <StyleAttribute name="position" value="center" />
  <StyleAttribute name="actionPanelPosition" value="bottom" />
  <StyleAttribute name="ringMenuPosition" value="bottom" />
  <StyleAttribute name="toolBarPosition" value="none" />
  <StyleAttribute name="statusBarType" value="none" />
  <StyleAttribute name="errorMessagePosition" value="popup" />
</Style>

Multiple Document Interface

Multiple Document Interface (MDI) is not applicable for Web applications.

Customization

It is likely you will want to apply some corporate styling to your user interface. For example, you may want to use your corporate colors or add your company logo.

Before you migrate your application, try out some of the customization exercises in Customization. For example, change the favicon image or add header text.

Behavior limitations

With the GDC, your application is an executable running on a front-end PC, and is therefore bound by the rules of what an executable can do within the operating system.

With the GBC, your application is running inside a browser, and is therefore bound by the rules of what Web pages can do inside a browser. As the Web browser is more vulnerable to intrusive attacks, you need to consider how much control you have over the accessibility and security of this environment. If you find the browser too restrictive, consider what a malicious Web site would do if it could:

  • Complete a file transfer without user permission.
  • Perform front-end calls to your disk.
  • Access APIs on your system.
  • Print immediately to the local printer

This section recommends ways to perform these tasks securely.

File transfer

File transfer in GBC is not transparent. The browser requests user permission before downloading anything on the client side.

GDC front-end calls

Calls by the front-end that access the desktop file systems (disk) are not supported. Check the available front-end function calls for GBC in the Built-in front calls section of the Genero Business Development Language User Guide.

The alternative is to write your own front-end call in JavaScript. For more information see the Implement front call modules for GBC topic in the Genero Business Development Language User Guide.

GDC embedded APIs

APIs such as WinDDE, WinMail, and WinCOM - used for data exchange and communication with Microsoft applications - are not supported by GBC.

The alternative is to use the server-side Java API solutions for Microsoft documents, such as those provided by Apache. For more information, see the topics about the Apache POI framework in The Java interface section of the Genero Business Development Language User Guide.

Printing to local printer

Printing immediately to a local printer is not supported. The local printer must first be registered on the server and print commands must originate from the back-end server.

As an alternative, you can select File >> Print from the browser.

Keystrokes

Some browsers may not allow some or all keystrokes to pass through to the application. It is possible (as in the case of tablets and smartphones) that the device does not perform keystrokes. You should review your sources and review your dependencies on keystrokes. For example, use ON ACTION instead of ON KEY.

It is also recommended to review the text messages displayed on the screen. Consider the following message:

Press <ENTER> to continue

If you have messages like this displayed on your screens, you may need to rewrite the message.

License count

Our intent is for your GBC to use the same number of licenses as a desktop application. However, there are two cases where you may observe a difference:

  1. If you close a browser tab or a browser window, it does not send a signal to the fglrun process to stop. It will continue to consume a license until a timeout period (default 5 minutes) is reached.

    NOTE: Even though the same occurs if you close the GDC by killing its process, it is more probable that a user will close their browser tab than kill a GDC process.

    If you have a low number of licenses or run close to your limit of user licenses, you may need to add extra licenses to lessen the chance of running out of licenses. With a CPU license this is not an issue. For more information see Multi-user Licensing in How Genero Licensing Works.

  2. We can identify that a program has launched another program via RUN (or StartMenu) commands. This results in the same license being used with no extra consumption of licenses. However, if you type an application URL into a browser or click on a link, there is no way of matching that up to an existing Genero program running in a browser and/or on the same PC. If you use a third-party menu system, you may find that your license consumption increases if users run multiple programs. If you use a third-party menu system, use a CPU-based license.

For more information contact your local sales office.

Evaluate authentication

Most GDC applications connect to the server with its user permissions and profile. As a result, the applications are run under this user identity.

When applications are deployed through GAS, they are launched as the user that started the GAS, unless the GAS is set to impersonate.

As the application user is different, this can have an impact on use of environment variables and permissions. The setting for the HOME environment variable, for example, may not be for the user you intended, and the ability to read/write files and execute sub-shells may also be affected by different user permissions.

You need to review your sources to determine how dependent you are on environment variables. If you do not already have one, it is probable that you need to add the concept of an application user to your application. You also need to consider how this user is authenticated. This may mean adding your own login/password dialog, or using SSO or Web server authentication.

In any case, it is recommended to migrate the application first on GDC over HTTP. If the application runs on the browser, no further action is required. Otherwise, depending on authentication needs, adaptations to your application may be needed.

  • Single sign-on (SSO) authentication

    The SSO authentication mechanism now works for both GDC and GBC. If you were using SSO with GDC, you can continue to use it with the GAS. See How to implement Single sign-on (SSO) in the Genero Application Server User Guide for more details.

  • Web Server authentication

    Web servers such as Apache or Microsoft IIS provide simple authentication mechanisms. If you use the Web server's authentication mechanism, the login details are transmitted to Genero applications by the dispatcher in an environment variable. The user login can be retrieved from the runtime environment with the FGL instruction:

    fgl_getenv("FGL_WEBSERVER_REMOTE_USER")

    For more details, see the fgl_getenv topic in the Built-in functions chapter of Genero Business Development Language User Guide.

  • Application login

    With an application login, there is nothing additional to do as the application handles the login.