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?
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).
This seems nuts to me. The existence of the procedure is known at the start, regardless of how long it may be.
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..
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.
BTW, I have opened case #
00273229
to request enhancement here.
bug.
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
community.progress.com/.../rationalize_procedure_references_in_xref.aspx
"....it was determined that the Progress Software product is functioning as it was designed".
Badly designed then?
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.