I have a subroutine (below) that references two associated mv fields. The subroutine is called as a pre-prompt process of the second field. It displays a popup of text values for that field based on the value entered into the first field of the amv set. I use this subroutine in two similar windows that use the same data and dictionary files.

In one version of the window, it works just fine. A second version of the window has a multi-valued symbolic field following the fields referenced by the subroutine, and the subroutine won't work in that window. No error messages are generated; it's as if the routine is completely ignored. If I remove the mv symbolic field from the window, it works fine. Ideas, anyone?

We are using AREV 2.12 running off a Novell 4.11 server (with the NLM v 1.5) the client workstations use Windows NT4.

EXPENDABLE SUBROUTINE POP.NOTE.SUBFIELDS

* Author: Tom Harkins

* Purpose: This routine calls a popup for a field based on the value

* entered into another field. This variation displays text pop-ups for

* use with various MARC note tags. {NOTE.TAG} and

* {NOTES.MARC} are a set of associated multivalued fields.

* {NOTE.TAG} is the first member of the set. The routine is called as

* a pre-prompt process of {NOTES.MARC} in the CATALOG

* and ACCESSIONS files.

$INSERT UTILITY_PROGS,AREV.COMMON

$INSERT UTILITY_PROGS,WINDOW.CONSTANTS

DECLARE FUNCTION CATALYST

CURR.TAG = '

CURR.TAG={NOTE.TAG}

CURR.NOTE={NOTES.MARC}

; * Don't display popups when editing an existing note.

IF CURR.TAG AND NOT(CURR.NOTE) THEN

  BEGIN CASE

  CASE CURR.TAG=049';CALL CATALYST("P","POPUPS*HOLDINGS")

  CASE CURR.TAG=260';CALL CATALYST("P","POPUPS*IMPRINT")

  CASE CURR.TAG=300';CALL CATALYST("P","POPUPS*CONTAINERS")

  remaining case statements on the same pattern - 25 or so

 END CASE

END

I dunno, looks fine to me. I'd try playing with the symbolic recalculation settings.

Just a thought. Your code is seems to be called only from a window.

You might try the following:

RECSAVE=@RECORD

IDSAVE =@ID

MVSAVE =MV OR @MV

DICTSAVE=@DICT

CURR.TAG={NOTE.TAG}

CURR.NOTE={NOTES.MARC}

; * Don't display popups when editing an existing note.

IF CURR.TAG AND NOT(CURR.NOTE) THEN

BEGIN CASE

* note – all of the calls below will set @ANS and, may set other

* system variables as well (@RECORD, @ID, @MV, etc.). They probably

* won't set AREV COMMON vars, although I have seen dict elements which

* have been expressly written to do so…

CASE CURR.TAG=049';CALL CATALYST("P","POPUPS*HOLDINGS")

CASE CURR.TAG=260';CALL CATALYST("P","POPUPS*IMPRINT")

CASE CURR.TAG=300';CALL CATALYST("P","POPUPS*CONTAINERS")

remaining case statements on the same pattern - 25 or so

END CASE

END

@RECORD=RECSAVE

@ID =IDSAVE

MV =MVSAVE

@DICT =DICTSAVE

…

RETURN

The reason for this is that the symbolics in your popup may alter these values in a way that futz's up your screen variables. Remember that these variables are Global. For example, a {DICT_CALL} will set @ANS and, if not properly written can mess up @RECORD, etc. as well

Don Miller

C3 Inc.

Don & Warren, thanks for the input. I've tried assigning some system variables in the subroutine before, and also varying the recalculation settings from the PAINT menu, but neither of these seem to make any difference.

Don, you wrote that "… reason for this is that the symbolics in your popup may alter these values…," but let me clarify. The popup does not use symbolics at all, just real fields. It's the presence of a symbolic field downstream in the window processing that seems to be the source of the problem.

I've been looking thru the documentation on the AREV COMMON variables as well….

Tom

The problem must be with MV being reset by the other multi-value field. It's possible that your symbolic is being recalculated as you move between fields and MV is not reset correctly because of the use of the subroutine in a pre-prompt process. Try inserting MSG into your code or DEBUG and display the value of MV that is actually being used by the code. You'll know two things. First, that the code is, in fact, being executed. Second, what the value of MV is.

I recall doing something similar in ARev 2.01 7 or 8 years ago. Let me see if I can dig up the code. No promises though.

Okay here we go, this routine calls a collector window as a preprompt process in AMVs. The idea is to allow SVM data entry into an AMV, sort of like doing a control-E but potentially allowing more control, the relevant section being PRESVM:

    SUBROUTINE SVM(BRANCH)

*————————————————————————-*

*

* Program ID : SVM

* Programmer : WDA

* Started : 15 JAN 1992

* Copyright : Copyright 1991 Athena Data Services. All Rights Reserved

* Revision : 1.0

*

*————————————————————————-*

*

* Purpose : Module to control a generic SVM window, called from any

* : prompt at pre-prompt time. Call as S SVM,PRESVM.

* :

*

*————————————————————————-*

*

* Modifications

*

* +—Date—+ By- Description————————-

*

*=========================================================================*

*—–

* INITIALIZE

*—–

*=========================================================================*

* M A I N P R O C E E D U R E

*=========================================================================*

    IF BRANCH EQ 'PRE_INIT' ELSE

$insert INCLUDE, AREV.COMMON

    END

$INSERT INCLUDE,LCPOSITIONS

    COMMON /CALLSVM/ SVMINFO

    declare subroutine MSG, FSMSG, STATUS_LINE

    declare function UNASSIGNED, INDEX_LOOKUP

    CP=SI ; CI=@ANS

    locate BRANCH in "PRESVM,PRE_INIT,PREP" using ',' setting POS then

       on POS gosub PRESVM,PRE_INIT,PREP

    end else

       MSG('Invalid Branch of %1%|Passed to %2%','','',BRANCH : @FM : TEMPLATE)

    end

    return

*—–

PREP:

*—–

    SCRIBE.FLAGS=1              ; * force editor to insert mode

    RETURN

*—–

PRESVM:

*—–

    @PSEUDO=@RECORD,MV]

    IF LEN(@PSEUDO) EQ 0 THEN

       @PSEUDO=IS.DFLT

    END

    SVMINFO=SI

    CALL CATALYST('W','SVM')

    @ANS=@PSEUDO

*CONVERT \FB\ TO \FC\ IN @ANS

    RETURN

*—–

PRE_INIT:

*—–

* Change Prompt variables

    PROMPT.LABEL=SVMINFO

    PROMPT.LEN=SVMINFO

    TEMP=LEN(PROMPT.LABEL)

    IF TEMP LT PROMPT.LEN THEN TEMP=PROMPT.LEN

    WINDOW.LEN=TEMP + 2

    TEMP=@RECORD

    TEMP              =PROMPT.LABEL

    TEMP           =SVMINFO

    TEMP           =PROMPT.LEN

    TEMP           =SVMINFO

    TEMP           =SVMINFO

    TEMP           =SVMINFO

    TEMP             =SVMINFO

    TEMP         =SVMINFO

    TEMP           =SVMINFO

    TEMP   =SVMINFO

    TEMP=SVMINFO

    TEMP      =SVMINFO

    TEMP   =SVMINFO

    TEMP      =SVMINFO

    TEMP   =SVMINFO

    @RECORD=TEMP

* Change window size

    @RECORD=WINDOW.LEN

    GOOF=FIELD(@RECORD,CHAR(247),2)

    GOOF=WINDOW.LEN

    GOOF=WINDOW.LEN

* Change Template skeleton

    WIN=FIELD(@RECORD,CHAR(247),9)

    SWAP 'Sub value' WITH PROMPT.LABEL IN WIN

*—–

* Put it all together

*—–

    @RECORD=FIELDSTORE(@RECORD,CHAR(247),2,1,GOOF)

    @RECORD=FIELDSTORE(@RECORD,CHAR(247),5,1,PROMPT.LABEL)

    @RECORD=FIELDSTORE(@RECORD,CHAR(247),9,1,WIN)

    RETURN

Ok, folks. Thanks for all your suggestions. I think I've figured it out. I had a number of horizontal multivalued fields in the affected window. These were being treated by PAINT as though they were amv groupings. When I saved the template, they would automatically be assigned grouping numbers, even though they were not grouped by me. It appears this was messing up the CURR.AMV.GROUP variable. I think the ability to paint horizontal multivalues came in with AREV 2.12, and I vaguely recall there being some problems with them. I repainted the fields to be 'normal' vertical multivalues, and set the symbolics to recalc according to dependency. This solved the problem.

–Tom

View this thread on the forum...