Page 1 of 1

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

Posted: Thu Mar 14, 2013 5:47 pm
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?

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

Posted: Thu Mar 14, 2013 6:13 pm
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,

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

Posted: Thu Mar 14, 2013 6:38 pm
by cklee
Thanks Mark, I would like to have a scrollable message box something like the one for regular web-event function.

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

Posted: Fri Mar 15, 2013 9:14 am
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.