How to display repository messages returned by file I/O?

Please do not use to report errors- use your regional help desk.
Please mark posts as being for RPG or RDMLX (LANSA) developer.
To subscribe by email, display this forum, scroll to the end and select ‘Subscribe Forum’.
Post Reply
cklee
Posts: 13
Joined: Fri Feb 08, 2013 7:05 pm

How to display repository messages returned by file I/O?

Post by cklee »

I have written a form with RDMLX to maintain the record of a file. In case validation error is encountered when the record is updated, any way to display the repository messages returned?
MarkDuignan
Posts: 346
Joined: Wed Apr 18, 2012 10:33 am

Re: How to display repository messages returned by file I/O?

Post by MarkDuignan »

This loop in a subroutine will read all the messages:

Subroutine ReadAllMessages
DEFINE FIELD(#ERRTXT)TYPE(*CHAR)LENGTH(132))

USE BUILTIN(GET_MESSAGE)TO_GET(#RETCODE#ERRTXT)
DOWHILE COND('#RETCODE=OK')
<< #ERRTXT contains the text of a message >>
USE BUILTIN(GET_MESSAGE) TO_GET(#RETCODE#ERRTXT)
ENDWHILE

Endroutine

Note that it simplest to use a subroutine in VL components - not a method.

How would you like to display them? eg: In a separate pop-over, in a scrollable message area, etc,
cklee
Posts: 13
Joined: Fri Feb 08, 2013 7:05 pm

Re: How to display repository messages returned by file I/O?

Post by cklee »

Thanks Mark, I would like to have a scrollable message box something like the one for regular web-event function.
MarkDuignan
Posts: 346
Joined: Wed Apr 18, 2012 10:33 am

Re: How to display repository messages returned by file I/O?

Post by MarkDuignan »

If you put a little Table element with no column headings and one column named MessageText (say) on the top of your form and cleared and (re)filled it in the subroutine that would do that. If you control the height of the table it would scroll - or your could let it expand and push the screen content down when multiple messages exist.

You could probably make this a generic shared method that many forms could reuse to display their messages. You make a VL #PRIM_OBJ object MYMethods (say) and add the generic method LoadMessages (say) to it. All the forms that want to use this method declare #MyMethods scope(*application) - so there is only one instance created - and then they can all reuse #MyMethods.LoadMessages.

For VL technical reasons I think that the actual message queue reading needs to be in a subroutine in the calling form - to make sure that the correct message queue is read - but that subroutine could then pass the messages (probably as a PRIM_ACOL collection) to the generic routine - which could clear and (re)fill a message table at row 1, column 1, spanning across all columns in the caller's form view.
Post Reply