Kbase P65454: 4GL considerations when migrating from Progress V6
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
02/02/2004 |
|
Status: Unverified
GOAL:
4GL considerations when migrating from Progress V6
GOAL:
Progress V6 4GL behaves differently in a GUI environment
FIX:
WHAT ARE 4GL CONSIDERATIONS WHEN MOVING FROM V6?
---------------------------------------------------------
Character-mode code written in Version 6 should for the most part run
identically in Version 7 and higher, provided you are also running
on a character mode platform in those versions.
Complete compatibility CANNOT be guaranteed when porting Version 6 code
to a Version 7 or higher graphical user interface (GUI) mode.
IF YOU WISH TO RUN YOUR VERSION 6 CODE ON A V7 OR HIGHER *GUI* PLATFORM
THEN YOU SHOULD ANTICIPATE MAKING EXTENSIVE CHANGES TO ACCOMMODATE
NATIVE USER-INTERFACE BEHAVIORS WHICH ARE BEYOND THE CONTROL OF
PROGRESS.
How do you know which type of PROGRESS you are running? The
easiest way to tell is to look at the PROGRESS executable you
invoke at startup. The executable _progres is a character mode
client. If you are running _prowin then you are running GUI
PROGRESS and should therefore expect that your Version 6 code
will require changes to work properly.
WHY WOULD MY V6 CODE WORK DIFFERENTLY ON A GRAPHICAL INTERFACE?
---------------------------------------------------------------
When running in a graphical environment such as MS-Windows, PROGRESS
must abide by the rules of that environment. Many of the issues
encountered when running Version 6 code in the GUI environment stem
from the fact that MS-Windows controls screen display in a manner
which was not encountered on versions prior to Version 7.
As a result, certain Version 6 language constructs behave differently
in GUI environments such as MS-Windows. This different behavior
may show up in the form of strange cursor behavior, text appearing
in unexpected places, or an apparent loss of keystrokes. The
4GL statements and phrases below have been shown to exhibit these
behaviors when ported to a GUI environment:
CHOOSE statement
PAUSE statement
PUT SCREEN statement
READKEY statement
Editing phrase
PUT CURSOR statement
Further problems may be encountered when Version 6 code makes use
of the entire width of a frame in displaying variables, labels,
titles, and/or text. Graphical environments typically require one
character-width on the leftmost and rightmost sides to accommodate
the window borders. This means that frames that make use of their
maximum width might generate runtime errors due to their size
suddenly being too great.
Finally, Version 6 DOWN frames may appear to scroll more slowly
when being used on GUI platforms. One reason for this is the DOWN
frame's characteristic as an iterative structure. GUI frames are
expected to be used as static, non-iterative displays. The DOWN
frame scrolling algorithm was not developed with this type of
environment in mind, so when ported to a GUI environment the screen
painting becomes considerably slower.
SHOULD I CONVERT MY VERSION 6 APPLICATION TO MAKE IT RUN ON GUI?
----------------------------------------------------------------
One option is to remove the statements and phrases listed above from
your Version 6 application and replace them with V7 and higher "GUI"
constructs that generally do the same thing. For the most part,
however, this is not recommended.
One reason this approach usually fails is that cursor behavior and
display characteristics get further confused due to the mixture of
character-mode programming techniques and GUI-mode techniques.
The informal term for this is "sprinkling GUI". Generally, a
program created by sprinkling GUI onto a procedure-driven
Version 6 application will generate runtime "wait-for" errors and
display annomolies that bring into question the entire worth of such
an undertaking.
WHAT IF I RUN MY VERSION 6 CODE ON A CHARACTER-MODE V7 OR HIGHER PLATFORM?
-------------------------------------------------------------------
If you run your Version 6 code on a Version 7 or higher character
mode client, for the most part you should see your program behave
and perform the same. There are some very limited exce.ptions,
however. One of these is the case of PUT SCREEN and PUT CURSOR.
One reason for this is the character-mode "window manager" that
exists on TTY Version 7 and higher. This window manager was
overlayed on top of the standard PROGRESS client in order to allow
GUI programs to run properly when ported to the character-mode
clients. As a result, there again is a problem where PROGRESS does
not always have complete dominion over the screen where it is
displaying. PUT SCREEN and PUT CURSOR are instances of this. If your
V6 code makes use of these statements then you should do
extensive testing on Version 7 and Version 8 to make sure you are
not affected by the limitations.
Additional issues have been seen where, after frames have been
displayed and hidden, there are characters left behind on the
display. This screen garbage is a result of the character-mode
window-manager being unable to "remember" where it had displayed
a character, thus making it "forget" to clear the character away
before displaying the next frame. Progress Development has been
doing its best to address the screen garbage problem and in many
scenarios has been able to resolve it.
CONCLUSION
----------
Progress will do its best to assure compatibility between Version
6 programs and the Version 7 and higher character-mode platforms.
Version 6 programs can be expected to encounter difficulties when
ported to V7 and higher GUI environments, including MS-Windows. Progress
cannot guarantee 100% compatibility in such cases. As a result,
programmers should expect to make code changes if they wish to use
the V7 and higher GUI environments, but expect minimal difficulty when
running on a V7 or higher character-mode environment.
It is not recommended that Version 6 programs be modified using new
event-driven 4GL constructs, since "sprinkling GUI" in this manner
brings its own set of headaches.
Before deploying to Version 7 or higher character-mode PROGRESS,
programmers should carry out thorough testing. Attempts to run
Version 6 programs in V7 or higher GUI PROGRESS should be accompanied by
even more extensive testing, as this is where a programmer will
see the greatest challenges..