Welcome to the Code Parse Group! Be sure to subscribe, and don't forget to click "my subscription" if you want to subscribe to the mailing list.
If you have multiple object creation statements, prolint incorrectly warns that you have a "Possibly Group Assign". However, you cannot use ASSIGN on object creation statments.
e.g.
CONSTRUCTOR PUBLIC ActionGroup ():
CommissionObject = NEW MyApp.Library.CommissionObject().
RuleObject = NEW MyApp.library.RuleObject().
END CONSTRUCTOR.
generates the warning incorrectly.
when parsing a class using properties, if you specify some code in the GET, prolint warns
"library\SessionSingleton.cls:9:11: expecting PERIOD, found '('
the code is:
DEF PUBLIC PROPERTY SystemDate AS DATE NO-UNDO
GET():
/* some code here */
END GET.
Generally, using unqualified field names is not viewed as "best practice" for 4gl developers. There are a number of pitfalls in using unqualified field names, one of the most significant is that when moving code around you can accidentally change which buffers are being implicitly used for the unqualified fields. This can lead to bugs that are rather difficult to track down.
ProRefactor has the semantic and contextual knowledge necessary to determine which buffer name is being implicitly used for unqualified field names. This refactoring finds unqualified field names in the current file (must be a compilable file) and adds the appropriate table or buffer names.
This refactoring is intended to be used as part of a legacy code modernization project. It is unlikely to be used on a day-to-day basis.
This feature assists in the transformation from string concatenation to the use of a single string with SUBSTITUTE
. This is done because the full sentence in a single string is easier to translate (for internationalization) than the sentence fragmented into two strings.
In some cases, ProRefactor may be unable to automatically suggest changes to the source code. You will be informed of this by a message, and you will be able to make the code change by hand if desired.
This refactoring finds and changes all hard-coded references to database table and fields that you want to rename. You select the projects or directories that you want to change, input a list of old and new names, and the refactoring writes the modified files to an output directory which you can review before merging the changes into your source.
Here is an example renaming list:
This refactoring is intended to be used as part of a legacy code modernization project. It is unlikely to be used on a day-to-day basis.
Although most Progress programmers recognize that NO-UNDO
is important for application performance, it is not unusual to find legacy applications where NO-UNDO
was not consistently added to DEFINE
statements. This refactoring is intended to be run as a single pass through old code, in order to correct those statements.
This NO-UNDO refactoring has a few features which are worthy of note.
This refactoring is intended to be used as part of a legacy code clean-up project. It is unlikely to be used on a day-to-day basis.
This refactoring allows you to automatically:
This refactoring checks if an include file is changed multiple times for multiple compile units. If the changes are different for different compile units, then the include file is not written to the output directory, and warning messages are issued.
This section describes each of the refactorings available from ProRefactor's user interface.
This section describes how to load ProRefactor source into an Eclipse workspace, so that you can use it and reference it from your own projects.
Experience programming in Java with Eclipse's IDE is not necessary, but since these instructions gloss over a few details, it would be helpful if you were familiar with Eclipse basics such as creating a Java project.
-ea -Xss2M
to the default VM args. This enables assertions, and sets the stack size to be large enough for recursively descending large syntax trees.
This section reviews the general aspects of the user interface which are not specific to any one refactoring feature. It also reviews user interface features which are unrelated to refactoring.
It is beyond the scope of this document to describe the Eclipse Workbench in any detail, however, a few quick notes and terms will make the rest of this chapter more understandable if you are new to Eclipse.
ProRefactor contributes menus to various parts of the Eclipse workbench. By default, these ProRefactor menus are only available when you are in the ProRefactor perspective. In the main menu bar, across the top of the workbench window, a ProRefactor menu is available.
Users of most IDEs are familiar with the concept of a project, but there are a few points of interest which are unique to Eclipse projects and ProRefactor.
Eclipse projects may have one or more natures. Because Eclipse is an IDE for many types of development environments, it also recognizes that any individual project could contain source code for two or more different sorts of development environments, for example, both C++ and Java. Each project nature describes various attributes for a project, such as which project builders are available within the project. (i.e. There would be a builder for compiling the C++ code, and a builder for compiling the Java code.)
ProRefactor is an Eclipse plug-in, and Eclipse provides a user interface to make the installation and updates of plug-ins easy. If you have ever used Eclipse's Feature Updates wizard in the past, then you probably do not need to read this section at all.
ProRefactor and Eclipse require a recent version of Java. Java can be freely downloaded and installed from java.sun.com.
ProRefactor requires a recent version of Eclipse. Eclipse can be freely downloaded and installed from www.eclipse.org.
Add -vmargs -Xss2M
to your shortcut for running Eclipse.
Proparse requires a large stack in order to store all nodes of a large program in memory. Since it was Java that loaded Proparse, it is the Java Virtual Machine which needs to be configured for running with a large stack.
If the stack size is not large enough, the JVM will shut down with a stack overflow error, but you will not see any error details when launching Eclipse and javaw.exe
as Windows processes. It doesn't take a huge program to cause this stack overflow. A program with one or two thousand lines of COMPILE statements is enough to do it. The stack size for javaw.exe
by default is 1MB. The argument -vmargs
tells eclipse.exe
to pass any following arguments on to the JVM. The argument -Xss2M
tells the JVM to set the stack size to 2MB.