knowing if an R-Code is GUI/TTY or independent?

Posted by Admin on 08-May-2013 10:15

Hi all, is there a way (similar to attributes of the RCODE-INFO system handle) to know if an R-Code is bound to a certain UI system?

As I didn't find an ABL solution, I tried already looking at the RCODE itself. Looks like the 5th byte of an RCODE (among others) changes when you compile the same .p in GUI and TTY. Am I on the right track there? Is there an (unofficial) documentation somewhere?

All Replies

Posted by jmls on 08-May-2013 11:05

can you run the program and trap the runtime error if it's the wrong

environment ? There's a specific error number for incompatible display types


Posted by Admin on 08-May-2013 14:16

HI Julian,

In theory that would probably work - but it's not practically applicable to my situation.

The use case I have relates to a migration of a large amount of legacy code. Due to a construct of include files procedures that shouldn't (like DB triggers) are using (SHARED) FRAMEs and thus become UI system dependent which complicates the whole setup.

I was hoping to be able to have a post build job running on Jenkins that automatically reports if those parts of the system that shouldn't are still UI system dependent.

Kind of what you can do with RCODE-INFO:DB-REFERENCE. Looks like the UI System was forgotten by PSC when they added the RCODE-INFO system handle.

Posted by Matt Baker on 08-May-2013 20:07

byte 5 is just part of a compile timestamp.  It will change on every compile.

The windowing system flag is buried deep in the r-code.  You won't find it easily without chasing a chain of byte offsets.

Of course I could tell you which ones and where...but then...well, you get the idea.

Posted by Admin on 09-May-2013 03:56

Hi Matt,

thanks for the feedback.

I have no problem with having to follow a few references in the R-Code before I get to the info. I assume there is no paper available describing this?



Posted by jmls on 09-May-2013 04:16

isn't the problem going to be that different versions of progress have

different references in the r-code - or is this a one-off for a particular

project ?

my mind is still boggling that there is a frame reference in a db-trigger


Posted by Admin on 09-May-2013 04:46

Legacy code. From times when you were still using include files...

Posted by Thomas Mercer-Hursh on 09-May-2013 09:17

One solution would be to simply recompile it in a systematic way and then you would know what the r-code was!

Posted by Evan Bleicher on 09-May-2013 09:44

Hi Mike:

We have discussed, but never implemented, providing an attribute on RCODE-INFO to reflect the display architecture required by an rcode file.


Posted by Admin on 09-May-2013 10:16

Dear. Dr., I’m already preparing to compile it in a controlled environment. I’ve also mentioned the Jenkins environment in this post.

But knowing where it was compiled will always only tell you half the truth:

Compile in prowin32: r-code is either GUI-only or UI system independent

Compile it in _progress: r-code is either TTY-only or UI system independent

Don’t see how that would help.

Posted by Admin on 09-May-2013 10:16

Hi Evan, was it due to the lack of use cases? It’s hard to believe such an attribute would be a lot of work.

Posted by Evan Bleicher on 10-May-2013 08:44

Hi Mike:

I agree it is not difficult to implement,however there is an impact on QA and we need to review the other team assignments and commitments for 11.3.  I will respond to this thread, once we have completed this analysis.

If we did implement a new RCODE-INFO attribute (DISPLAY-TYPE), what is your opinion on what it should return for the case when the .R file is display type agnostic?  The working model is that this character attribute would return "GUI" and "TTY".  For display type agnostic, we could return "None", or "".  or something else. Your input?



Posted by Admin on 10-May-2013 08:56

Hi Evan, thanks for considering that!

For the display type agnostic case, I would not introduce another word, like "None". I'd rather for the empty string or ?.

I could live with any case.

Posted by Thomas Mercer-Hursh on 10-May-2013 09:19

Whereas I would think a different word would be more positive.   "" or ? could be the result of a failure to work properly.

Posted by Peter Judge on 10-May-2013 09:31

The failure of what to work properly? If the RCODE-INFO is a valid handle, then all the available information about that rcode is available. ? in this case seems logical to me.

-- peter

Posted by Thomas Mercer-Hursh on 10-May-2013 09:46

*If* it is a valid handle ... that is the point.   If you do the test and come out with "None", then you have a positive indication that the test worked properly and you have a clear answer.  If you get a ?, then you have to determine whether or not that is a valid result.   This is not a position I take specific to this test, but a general principle that it is better to get a clear, definitive response indicating state.  ? should mean, state is unknown.  In this case, the state is clearly defined and entirely different from GUI or TTY.

Posted by Admin on 10-May-2013 09:56

After looking at the other properties of the RCODE-INFO (or FILE-INFO) handle, I'd rather use the empty string for display type agnostic.

The unknown valud typically indicates the I passed a wrong value to the FILE-NAME at the first place.

Posted by jmls on 10-May-2013 10:06

"PORTABLE" would be my choice

Posted by Peter Judge on 10-May-2013 10:11

If you don't have a valid handle, calling the property on it will fail.

-- peter

Posted by Admin on 10-May-2013 10:16

Like an UI for portable devices?

I'd rather use a clearer term...

Posted by Admin on 10-May-2013 10:16

RCODE-INFO handle invalid?

Call me naive - but it's still an 4GL where a static system widget is always accessible.

Posted by Peter Judge on 10-May-2013 10:26

I appreciate you calling yourself naïve rather than me wrong (which is, of course, more accurate).

Since the RCODE-INFO handle is a system handle and so always valid, Thomas's approach is the correct one. ? is returned when the RCODE-INFO handle doesn't actually point at any rcode.

"NONE" might be more accurate since it refers to no UI-specific code.

Would there be value in separating ABL GUI from .NET GUI in the response?

-- peter

Posted by Admin on 10-May-2013 10:31

Would there be value in separating ABL GUI from .NET GUI in the response?



Since both GUI's use the same runtime and both GUI's could be used in the same R-Code.

Posted by Thomas Mercer-Hursh on 10-May-2013 10:49

Isn't the point that this piece of R-code has no UI rather than that it can be used in either?

None or NoUI seems more to the point.

Posted by Evan Bleicher on 16-May-2013 12:43

HI All:
We will be able to provide a DISPLAY-TYPE attribute off of the RCODE system handle in the 11.3 release.
Mike, thanks for raising this issue.
A portion of the functional spec for this change states:

DISPLAY-TYPE attribute

We will introduce a new attribute named DISPLAY-TYPE to the RCODE-INFO system handle that returns the display type forthe given r-code file.

Data type: CHARACTER
Access mode: read-only
DISPLAY-TYPE returns one of three values: “GUI”, “TTY” or a blank string (“”).
If the r-code is generated using a GUI client andcontains UI-specific statements, it can only be executed by a GUI client. Ifyou query the DISPLAY-TYPE attribute, it will return the string “GUI”.
Similarly, the DISPLAY-TYPE attribute returns the“TTY” string for r-code that was generated by a TTY client and containsUI-specific statements.
The DISPLAY-TYPE attribute returns a blank string(“”) if the r-code does not contain any UI-specific statements, in which caseit can be executed by either a GUI or TTY client, independent of the type ofclient that generated the r-code.
This is an example:
RCODE-INFO:FILE-NAME = “filename.r”.
If you query the DISPLAY-TYPE attribute beforesetting the FILE-NAME attribute to some r-code file, as with other attributesin RCODE-INFO, the DISPLAY-TYPE attribute returns the unknown value.
Note: it goes without saying that this onlyapplies to 11.X r-code, as a 11.X client can only read 11.X r-code.

DISPLAY-TYPE on SESSION system handle

Note that we already have a DISPLAY-TYPEattribute on the SESSION system handle that allows the developer to get thedisplay environment of the running session (it returns either “GUI” or “TTY”).The attribute is also a read-only attribute in the case of SESSION. We will just need to expand the documentation for DISPLAY-TYPE to include that it applies to RCODE-INFO and the behavior when applied to RCODE-INFO vs. SESSION.

Posted by Admin on 16-May-2013 12:51

Thank you Evan!

This thread is closed