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

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

Julian

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.

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.

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?

Regards,

Mike

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

...

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

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

Hi Mike:

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

Evan

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.

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.

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?

Thanks

Evan

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.

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

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

*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.

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.

"PORTABLE" would be my choice

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

-- peter

Like an UI for portable devices?

I'd rather use a clearer term...

RCODE-INFO handle invalid?

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

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

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

No.

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

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.

DISPLAY-TYPE on SESSION system handle

Thank you Evan!