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.
This Groovy script was the original prototype, proof of concept. It generates lots of useful XML, but we decided rather than go from Proparse+Groovy through XML into ABL programs, it would be better to work on the new Proparse ABL API so that we are working with Proparse+ABL right off the bat.
Download the zip file (attached below), unzipping creates a directory called 'guibom'.
Download proparse.jar and put it in that guibom directory.
Would it be hard to support smartobjects like smartframes, smartviewers,... in a smartwindow with PRO/Dox?
When a window has a variable defined in the definitions section, and an internal procedure defines that same variable internally, PRO/Dox results in a duplicate variable being found in the generated pdx file. Any suggestion for a fix? (other than running through our 14000 files to fix these duplicate variables that may or may not be intentional.)
Gooey bomb?!
This project is for building a Bill of Materials of frames and widgets. Such a BoM may have many uses, but the immediate goal is for assistance in conversion of existing ABL to use new .Net UI.
The GuiBom is composed of lists of frames, fields, and widgets in a given compile unit, as well as their attributes and links to nodes in the syntax tree where the frames and widgets are referenced. A proof of concept script has already accomplished much of this. The BoM goals appear to be straightforward to achieve by using the new version of Proparse.
Came across an interesting thing today. The following code works fine in 10.1C, but not in 10.1B:
FUNCTION Test RETURNS LOGICAL (p_Data AS LONGCHAR):
RETURN YES.
END FUNCTION.
MESSAGE Test("data") VIEW-AS ALERT-BOX INFORMATION.
looks as if 10.1C can mix and match char with longchar, something that I've always wanted to do since longchar became available.
Seems as if Progress are making changes to the language for the better. Now, if only they had a 4GL way to deal with sockets, instead of all this READ-RESPONSE-PROCEDURE and memory pointers etc !
I posted a new build of the standalone prorefactor.jar file. The previous build had an error.
FileRefs.groovy
May 2008 by John Green.
Find and fix code developed on Windows so it has file references which are portable to unix.
Does the following for RUN *.p, RUN *.w, and for include file references:
the following line
CLASS foo INHERITS bar USE-WIDGET-POOL :
generates a unexpected token: USE-WIDGET-POOL
the following code:
REPEAT FOR CampaignData TRANSACTION lv_i = 1 TO 100 :
gives the incorrect rule :
FOR CampaignData has no NO-LOCK / EXCLUSIVE-LOCK
I have the following line:
DEF PUBLIC PROPERTY ObjectGUID AS CHAR NO-UNDO INIT ? GET. PRIVATE SET.
this generates the error:
23:52: unexpected token INIT
Hello,
I've managed to set up the code to xml groovy script published on this website and would like to use it to determine the following:
/* Sample code, parsed with errors */
DEFINE VARIABLE hCustomer AS HANDLE NO-UNDO.
DEFINE VARIABLE hQry AS HANDLE NO-UNDO.
CREATE QUERY hQry.
hQry:ADD-BUFFER(BUFFER customer:HANDLE). /* parsing error: Expecting RIGHTPAREN, found : */
hQry:QUERY-PREPARE("For each customer no-lock":U).
hQry:QUERY-OPEN.
hQry:GET-FIRST.
/* Sample code, parsed with NO errors */
DEFINE VARIABLE hCustomer AS HANDLE NO-UNDO.
DEFINE VARIABLE hQry AS HANDLE NO-UNDO.
CREATE QUERY hQry.
hCustomer = BUFFER customer:HANDLE.
hQry:ADD-BUFFER(hCustomer). /* no parsing error */
This script allows you to generate XML for each of your compile units. The XML contains the entire syntax tree, as well as the symbol tables. This XML is a very raw dump of Java objects from memory.
What is the benefit of this? It allows you to use OpenEdge scripts to gain access to all of the useful information that is generated by ProRefactor. For example, you might use the XML as input for ABL scripts to generate code documentation, to augment your XREF indexes, or to allow you to perform ad-hoc search and analysis.
Scripting opens up endless possibilities for working with ProRefactor and the syntax tree.
There are various scripting languages available for running on the Java Virtual Machine (JVM). Those include Groovy, Jython, JRuby, Rhino Javascript, and others. Any of those should allow you to access ProRefactor as a library, and run the parsing and analysis programs it contains. I chose Groovy because I found that Groovy had the cleanest interfaces between its scripts and existing Java applications and libraries like ProRefactor.
A recent client requirement got me into ProRefactor to add some more goodies to the symbol tables. The requirement was to find all database fields that could be updated in the UI for all frames in each compile unit.
It wouldn't have been too much work to write a script to walk through the syntax tree to figure this out, but it really seemed like something that should be easily available from the symbol tables. And, it seemed like something that would be easy to add to the tree parser in ProRefactor.