I'm working on an Arev 3.12 application. I've already written the subroutine code within a program to do the validation on a window's prompt. What I'm having trouble with now is calling the subroutine from the prompt's validation pattern so it can do its checking and give me a thumbs up or thumbs down (with appropriate error messages). I've tried several things that were suggested in the manuals, the help screens and this discussion area. Can anyone make a suggestion?

Our standard for the code behind a window is to use one program and call the appropiate subroutine within it. So the program has one value passed into it. Then the main module checks to see if the value is a vaild subroutine that can be called from outside. If everything checks out the subroutine is called and it does its thing. That is what I'm trying to do here.

The one thing that has gotten me at least a break to the debugger is when I put the program name and subroutine name (seperated by a comma) all between square brackets (). This told me that there were too many parameters passed to the program. Everything else I've tried has done nothing for validation.

I've tried things like:

@S PROGRAM_NAME,SUBROUTINE_NAME@

CATALYST('S','PROGRAM_NAME,SUBROUTINE_NAME')

PROGRAM_NAME,SUBROUTINE_NAME this one gave me the error message.

Thank you for your time,

Michael Slack

First, the brackets tell the system what it's using is a user conversion, where ProgramName,Subroutine results in @ANS being fed to ProgramName and the program using whatever is in Subroutine as the third parameter of the conversion: i.e.

expendable SUBROUTINE ProgramName(ConvType,DataIn,Subroutine,DataOut)

In @S ProgramName,Subroutine@ the system calls ProgramName and passes it a parameter of Subroutine. It is exactly equal to:

call ProgramName(Subroutine) where Subroutine is just a passed parameter like call TO_UPPER(String)

If you want to call a subroutine WITHIN a program, you use whatever is in Subroutine as a branch name - i.e. it might be a parameter used in a CASE statement to branch within the program.

[email protected]

http://AdvancedRevelation.com

Michael,

How are you handling the literal string represented by "SUBROUTINE_NAME"? Does it look something like this?

Called from validation pattern: @S WINDOW_PROGRAM,VALID@

SUBROUTINE WINDOW_PROGRAM( SUBROUTINE_NAME ) * DECLARE SUBROUTINE MSG, VIDEO.RW, INDEX.FLUSH, COLLECT.IXVALS, FSMSG DECLARE FUNCTION POP.UP $INSERT SYSINCLUDE,WINDOW.CONSTANTS $INSERT SYSINCLUDE,STATUS.CONSTANTS $INSERT SYSINCLUDE,WINDOW_COMMON% * FMC=SI ;* FIELD NUMBER * BEGIN CASE CASE SUBROUTINE_NAME=OPTIONS" GOSUB OPTIONS: CASE SUBROUTINE_NAME=VALID" GOSUB VALID: CASE SUBROUTINE_NAME=SAVE" GOSUB SAVE: END CASE * RETURN

OPTIONS:

* Options processing here

RETURN

VALID: BEGIN CASE CASE FMC=0 ;* THE ID FOR THE RECORD IF NUM(@ANS) ELSE STATUS()=0 ; * OR VALID=0 CASE FMC=1 CASE FMC=2 END CASE RETURN

SAVE:

* Save code here.

RETURN

If not, could you copy-paste-edit to show us how move through the main program to the subroutines? It sounds like the main program passes the parameter okay, but it's just not recognized by the subroutines as the program is executed. Thanks. Bill </QUOTE> —- === At 25 MAY 2000 02:56AM Curt Putnam wrote: === <QUOTE>Validations can be a little tricky. It seems to be much cleaner just calling a post prompt. You can pass whatever arguments (as a single string) as may be needed. Later, Curt </QUOTE> —- === At 25 MAY 2000 03:47PM Michael Slack wrote: === <QUOTE>I'll take your advice and use the post prompt to validate the prompt. I just got too focused in on the validation pattern that I lost sight of other possiblities. Thnaks, Michael Slack </QUOTE> —- === At 25 MAY 2000 04:07PM Michael Slack wrote: === <QUOTE>Here is a much cut down sample of the program I'm currently working with. The stuff within the MAIN module is generally how we handle calling a subroutine within a program from say a window or other places. Please note that the list within the CURRENT_SUB_LIST has to have exactly the same items in the same order as the list in the "ON POS GOSUB" line. I think you might find this method a lot easier to work with than a CASE statement. You can easily add or remove or change soubroutine names. As long as both lists are exactly the same and there is a subroutine by that name, it's happy. Only those subroutines named within the lists can be called from outside of the program. You can have as many subroutines as you want, assuming the ones not listed are called by other subroutines within the program. We've went this way so that in general we would have for every one data window we would have one program with all of the different processes in one place. I hope this helps, Michael Slack EXPENDABLE SUBROUTINE AREV_TO_ASCII_DS1_SUB(CURRENT_SUB) * * MAIN CURRENT_SUB_LIST=SUBROUTINE_1,' CURRENT_SUB_LIST := 'EOL_TEXT_VALIDATION' LOCATE CURRENT_SUB IN CURRENT_SUB_LIST USING "," SETTING POS THEN ON POS GOSUB SUBROUTINE_1,EOL_TEXT_VALIDATION END ELSE MESSAGE=ERROR IN AREV_TO_ASCII_DS1_SUB!' MESSAGE := '|SUBROUTINE NOT FOUND.' MESSAGE := '|"':CURRENT_SUB:'"' MSG(MESSAGE,MSG_MAP_A,,) END RETURN * END MAIN SUBROUTINE_1: * * RETURN EOL_TEXT_VALIDATION: * * Status=0 ;* Good pattern (this is the default) IF LEN(WC_IS%) ] 0 THEN VALUE_HOLD=WC_IS% SWAP ',' WITH @FM IN VALUE_HOLD CNT_VALUE_HOLD=COUNT(VALUE_HOLD, @FM) + (VALUE_HOLD # ) FOR I=1 TO CNT_VALUE_HOLD IF NUM(VALUE_HOLD) THEN IF INT(VALUE_HOLD)=VALUE_HOLD ELSE MESSAGE=THE VALUE OF "':VALUE_HOLD:'" IS NOT AN INTEGER NUMBER.' MESSAGE := '|ONLY INTEGER NUMBERS BETWEEN 0 AND 255 (INCLUSIVE),' MESSAGE := '|SEPERATED BY COMMAS (,) ARE VALID IN THIS PROMPT.' MSG(MESSAGE,MSG_MAP_A,,) Status=3 ;* Reprompt, no error message END IF (VALUE_HOLD =] 0) AND (VALUE_HOLD ⇐ 255) ELSE MESSAGE=THE VALUE OF "':VALUE_HOLD:'" IS OUT OF BOUNDS.' MESSAGE := '|ONLY INTEGER NUMBERS BETWEEN 0 AND 255 (INCLUSIVE),' MESSAGE := '|SEPERATED BY COMMAS (,) ARE VALID IN THIS PROMPT.' MSG(MESSAGE,MSG_MAP_A,,) Status=3 ;* Reprompt, no error message END END ELSE MESSAGE=THE VALUE OF "':VALUE_HOLD:'" IS NOT A NUMBER.' MESSAGE := '|ONLY INTEGER NUMBERS BETWEEN 0 AND 255 (INCLUSIVE),' MESSAGE := '|SEPERATED BY COMMAS (,) ARE VALID IN THIS PROMPT.' MSG(MESSAGE,MSG_MAP_A,,) Status=3 ;* Reprompt, no error message END NEXT I END IF STATUS=0 ELSE WC_WI_NEXT%=WC_WI% END RETURN </QUOTE> —- === At 25 MAY 2000 05:47PM Richard Hunt wrote: === <QUOTE>Geee… all I do is use the validation item in the window prompt. The subroutine has to be designed as a validation (or coversion) subroutine. It very simple, and I use it alot cus once the subroutine is created, it is so simple to replicate for other prompts. For example here is a "PHONE" validation. It a very brief display on how to do it. Ok in the validation item within the window prompt enter "PHONE". Now… The subroutine looks like this… SUBROUTINE PHONE(TYPE,VALUE,BRANCH,RETURN_VALUE) * – TYPE=the type of conversion, "ICONV" or "OCONV". * – VALUE=the value the user entered at input. * – BRANCH=is the extra items passed (slightly hard to explain so I wont). * – RETURN_VALUE=ON RETURN… the converted result (only on conversions not validations). * * Set up program variables. RETURN_VALUE=VALUE NUMBERS=1234567890' PHONE=RETURN_VALUE STATUS()=1 * * Internal convert the value. BEGIN CASE CASE TYPE EQ 'ICONV' * – Ok do the internal conversion. * – Something like convert "800-555-1212" to "8005551212". * – Be sure to set the "STATUS()". * * Output convert the value. CASE TYPE EQ 'OCONV' * – Ok do the output conversion. * – Something like convert "8005551212" to "(800) 555-1212". * – Be sure to set the "STATUS()". * * Return the converted value. RETURN_VALUE=PHONE RETURN END * * – Set the "STATUS()" to 0 if conversion was successful. *** – Set the "STATUS()" to 1 if conversion failed. </QUOTE> —- === At 25 MAY 2000 08:36PM Bill Titus wrote: === <QUOTE>Michael, Thanks for the sample code, which is interesting and helpful. Bill </QUOTE> —- === At 26 MAY 2000 09:49AM Michael Slack wrote: === <QUOTE>Hello Richard: I follow what your code is doing but the piece of the puzzle that still eludes me is how are the subroutine parameters being passed in? Since you call your Phone routine from the validation pattern of a prompt with PHONE, I don't see how the subroutine parameters of TYPE, VALUE and BRANCH are passed in. Are these in common variables some where? If that were the case then you wouldn't need to pass parameters, so I'm at a loss. For that matter, where is the RETURN_VALUE going? I would have expected that @ANS would be set somewhere before the end of the routine. Would you please give me a hint? I expect it's something simple and straight forward and I'll question my mental abilities once it's explained. Thanks, Michael Slack </QUOTE> —- === At 26 MAY 2000 11:42AM The Sprezzatura Group wrote: === <QUOTE>Saying means 'please call this as a custom conversion (UDC User Defined Conversion)' so the system automatically inserts these parameters. The Sprezzatura Group World Leaders in all things RevSoft </QUOTE> View this thread on the forum...