Procedures and includes in xml-xref

Posted by Thomas Mercer-Hursh on 22-Apr-2014 17:00

I was curious whether I could detect from the xml-xref that an include file occurred within a procedure, so I wrote a simple program

define variable i as integer no-undo initial 1.

run upone ( i ).

procedure upone:
  define input parameter j as integer no-undo.
  { test.i j }
end procedure.

In the xref-xml that comes from this, the INCLUDE reference is *before* the PROCEDURE reference and the line number of the procedure reference is at the *end* of the procedure, not where the PROCEDURE begins.  There is no reference on line 5 where the procedure definition is.

Is this expected behavior?

All Replies

Posted by Fernando Souza on 23-Apr-2014 08:31

This is the same behavior you get with the ASCII xref. The xref entry for procedures, functionc, etc is processed at the end of it, so the line number referring to the 'end' is a by-product of that. Even though it has always worked like this, I suggest you open a call with Technical Support to log an issue so we can look into having the actual line number logged. Note that the procedure entry would still come after the include entry in your example (just with the right line number).

Posted by Thomas Mercer-Hursh on 23-Apr-2014 09:42

This seems nuts to me.  The existence of the procedure is known at the start, regardless of how long it may be.

Posted by Fernando Souza on 23-Apr-2014 12:19

The complication here is that the entry for procedures contains information about the parameters and we need to process it to get the list of parameters and their datatypes, etc to be able to log them..

Posted by Thomas Mercer-Hursh on 23-Apr-2014 13:47

Wellll perhaps, but that doesn't mean that you need to forget the starting line number or put things out in the wrong order.It just means holding some stuff on a stack while you collect the information.  To issue it at the end, you are already holding the procedure and parameter information on a stack, so the only thing additional you would need to stack is the other calls that come along.

Posted by Thomas Mercer-Hursh on 23-Apr-2014 13:48

BTW, I have opened case #


to request enhancement here.

Posted by gus on 23-Apr-2014 16:27


Posted by Thomas Mercer-Hursh on 23-Apr-2014 16:38

Per Youssif Shanshiry

After researching your case 00273229, it was determined that the Progress Software product is functioning as it was designed.

I have created an Idea for it here

Posted by Nigel Allen on 23-Apr-2014 16:43

" was determined that the Progress Software product is functioning as it was designed".

Badly designed then?

Posted by Thomas Mercer-Hursh on 23-Apr-2014 16:57

Well, short sighted design.  Youssif explained that while the procedure is detected at the line where the word procedure occurs, in order to accumulate things like parameters, they need to keep it open.  Ultimately, I don't suppose one knows that one has everything.  While bizarre, I have tested that one can have additional parameters *after logic in the procedure, so one doesn't really know that one is done until one reaches the end.  So, I can see how someone did this, but clearly they didn't think very much about how it would be used.

Frankly, one of the key faults in the current design is the fixed properties that come under every reference, whether they make sense or not.  If the properties were specific to the reference type, one could have used this sequence, but supplied an beginning and end line number.

This thread is closed