Project

General

Profile

Default progress procedures

Added by Antanas Valencius about 3 years ago

Hello,

I played with the application that I converted, and noticed that there were errors during runtime. The error was about a missing procedure that the code was trying to run. I inspected and found out that the procedure is a default progress procedure (the sources can be found here: https://community.progress.com/s/article/P9621).

I tried downloading those procedures and copy them to ./abl folder to convert them. However, these did produce a lot of errors (missing files, maybe something else..). Then I tried to select the procedures I need by hand, but it was a pain because of dependencies.

How do I convert the code to include default progress procedures?


Replies (1)

RE: Default progress procedures - Added by Greg Shah about 3 years ago

We never use source code from the ADE tools downloads from Progress. The way to replace these depends upon what code you are talking about.

  • The most common dependency we've found is for GUI applications using the ADM/ADM2 framework. That framework has been largely unchanging for 2 decades. We have found it is quite easy to use the Possenet version of the code to make these applications work very well. Possenet is licensed under an unambiguously permissive open source license. It is safe to use. Possenet is just an earlier open source version of the ADE tools code. We convert a subset of the Possenet code needed for ADM/ADM2 as part of the conversion of an application which depends on that framework.
  • In the case of built-in 4GL OO classes, we have implemented a large number of those as part of FWD itself. See Supported OO Built-in classes. If you find a need for OO classes which are not yet supported, we can work together to add these to FWD.
  • The last category of code are the miscellaneous other procedures that sometimes get used from application code. This code is also typically present in Possenet and has not changed in 2 decades. The most common one we've seen is _osprint.p. Generally, we've found this code can be replaced quite easily. For example, we have features built in to FWD to eliminate the usage of _osprint.p. If we have no direct replacement in FWD, then one can include the code from Possenet and convert it with the application. However, we try to avoid it because utility code such as _osprint.p uses native code/WIN32 APIs and things like appbuilder use OCX controls. Still, most of Possenet that is just normal 4GL code will work fine.

Since you are using the term procedure, I guess you may be referring to this last category. Please provide more details about what specific procedures you are using. We may already have good alternatives in FWD.

    (1-1/1)