|
Sorry but that just looks painful...JMO... Thanks, Tommy Holden -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan G. Campin Sent: Tuesday, July 11, 2006 4:18 PM To: rpg400-l@xxxxxxxxxxxx Subject: RE: Subprocedure question Here is my take on subfile message handling. I use an external service program to wrapper all the message functions. That code is available at www.think400.dk/downloads under Trigger Mediator (About half way down the page). Also, this example code is available in the same package under TG0002_M02. The other modules contain similar logic. Would highly recommend that you use a Service Program to wrapper your message functions. If you look at the functions, they wrapper quite a bit of code and makes easy to use but that is my beef. Redeveloping the world in every program. I want to write it once and not worry about again. TG0002 provides a very clean example of developing a green screen using ILE, procedures and modules and includes a standard menu panel, standard edit panel, standard single page load subfile, standard Add/Change/Delete panel and standard validate delete panel. Anyway, hope this helps. Program name is imported from top level. I use one module per screen and bind to one program. d ProgramName... d s Like(StdNam) d Import System data structure to get module name. These are standard in every module. d SystemDataStructure... d sds 333 Qualified d ModuleName... d 1 10 d UserName... d 254 263 Constant for main procedure. d cMainProcedureName... d c Const('PROCESSSCREEN02') d ScreenOpen... d s Like(StdLgl) d Inz(cFalse) Here is main procedure code. Only thing to look at is the Program Message Queue Code. Note I am sending the main procedure name, the module name and the program name. If I call to a procedure that does error validation, it sends the message to program queue connected to this procedure, module and program. In this way, you do not have to worry about how many levels down you are in procedure. Messages are always sent back to the main procedures program message queue. * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * ProcessScreen02 * Do Processin for Screen 2 - Standard Input Panel. * Input - None * Out - None. * Returns - Key Pressed. * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - p ProcessScreen02... p b Export d pi like(StdChr) /copy *libl/qsrcf,CB_KEYP /Free If Not ScreenOpen; ScreenOpen = cTrue; Open TG0002_D01; EndIf; If ptrTriggerHeader = *Null; ptrTriggerHeader = USPC_GetPointerToUserSpace('TG_CTRL_HD': '*LIBL' ); EndIf; LoadScreenFields(); MSGF_ClearProgramMessageQueue(cMainProcedureName : SystemDataStructure.ModuleName: ProgramName ); DoU 0 = 1; DisplaySubfileMessages(); ExFmt RD01_02; MSGF_ClearProgramMessageQueue(cMainProcedureName : SystemDataStructure.ModuleName: ProgramName ); Clear ErrorIndicators; Send message to subfile message queue code. This code is inside a procedure. p Update... p b d pi Like(StdLgl) /Free TriggerHeader.THACTIVE = B_ACTIVE; TriggerHeader.THRELOADUS = SystemDataStructure.UserName; If B_RELOAD = cYes; B_RELOAD = cNo; TriggerHeader.THRELOADTS = %TimeStamp(); MSGF_SendProgramMessage('UTG0001': cXVMessageFileName : ' ' : cMainProcedureName : SystemDataStructure.ModuleName: ProgramName ); // Force screen to redisplay. Return cFalse; EndIf; Little bit of XVMSGF. Point here is that the message ise sent to a specific procedure, module, program. MessageDataLength = %Len(InMessageData); ProcedureNameLength = %Len(InProcedureName); ModulePlusProgramName = InModuleName + InProgramName; SendProgramMessage(InMessageId : InQualifedMessageFileName : InMessageData : MessageDataLength : MessageType : InProcedureName : MessageStackLocation : MessageKey : ApiError : ProcedureNameLength : ModulePlusProgramName: ScreenWait ); If ApiError.BytesAvailable <> 0; ERRH_Throw(ApiError.MessageId :
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.