knowing if an R-Code is GUI/TTY or independent? - Forum - OpenEdge Development - Progress Community

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


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

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

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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?



    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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

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

    Evan Bleicher

    Sr. Development Manager

    Progress Software

  • Thank you Evan!