19990615: bug or config error...? Mcidas-X 7.504

>From: Michael Voss <address@hidden>
>Organization: SJSU
>Keywords: 199906151839.MAA27123

Mike,

>I ran across this error, I'm not sure if it is a bug or indicates that I might
>have a configuration problem. Either way I thought I would let you know.
>
>When I run F5 from the 'Unidata Menu Administration' Menu I get:
>------
>BKGRUN {strnvals.gui}                                                         
>BKGRUN: Done                                                                  
>Error in startup script: can't read "str(?IFRM)": no such variable            
>    while executing                                                           
>"set $sname $str($sname)"                                                     
>    ("foreach" body line 6)                                                   
>    invoked from within                                                       
>"foreach txt $strntbl_name {                                                  
>                set sname [string range $txt [string last "?" $txt] end]      
>                global $sname                                                 
>                lappend string_names $sname                                   
>                set $sname $st..."                                            
>    (file "/home/mcidas/bin/strnvals.gui" line 161)   

The error "can't read "str(?IFRM)"" indicates that the menu definitions
stored in UNIMENU.DEF have not been restored to the string table that
is in use in your session.  If you have not copied UNIMENU.DEF to
your user's McIDAS working directory, then you need to do so.  For 'mcidas'
this would mean that you:

cd workdata
cp ~/mcidas7.5/data/UNIMENU.DEF .

For other users, the easiest thing to do is to run the 'userdata' script
that is located in the ~mcidas/admin directory.  Running 'userdata' with
no command line arguments will give you a synposis of what you need to
enter.

>I got to this point because I was trying to figure out the easiest way
>to manipulate the F-key menu to incorporate my longer loops.

You could simply add Fkey actions that brought up your long loops.

>As it stands now I'm staying with the Unidata SYSKEY, but I need to modify
>the UNIDATA.MNU file (I call it LOCAL.MNU). E.G. when I hit F5 from the
>Imagery Menu I see the command that makes the loop happen:
>-----
>EG 1  10;ALOOP 5000 5026 1  10 EC 32 130  -2 DWELL=3 10  MAP=YES H 9002
>EU=IMAGE SU=IRTEMP LIMIT=12 BAR=VER NO SF=YES 
>-----
>(I decided to save 27 images in 5000 to 5026)
>But this only displays the latest 10 images even though there are really 27
>there.

Right.  This is what ALOOP is being told to do with the '1 10' positional
parameters (start in frame 1 and load 10 frames).

>So, I need to change the menu commands such that the following is
>executed
>------
>EG 1  27;ALOOP 5000 5026 1  27 EC 32 130  -2 DWELL=3 10  MAP=YES H 9002
>EU=IMAGE SU=IRTEMP LIMIT=32 BAR=VER NO SF=YES 
>------
>
>Am I correct im modifying LOCAL.MNU?

Yes.

>If so, where does the .MNU file get '#?IFRMS' below,

From UNIMENU.DEF:

 ...
REM Image loop start frame and number of images to load:
REM   ?AFRMS - Antarctic composite
REM   ?FFRMS - Floaters
REM   ?HFRMS - Water Vapor
REM   ?IFRMS - Infrared
REM   ?MFRMS - Manually Digitized Radar
REM   ?VFRMS - Visible
REM

?AFRMS  "1  10
?FFRMS  "1  10
?HFRMS  "1  10
?IFRMS  "1  10
?MFRMS  "1  10
?VFRMS  "1  10
 ...

Once your McIDAS session can "see" UNIMENU.DEF (after you copy it to
your McIDAS working directory), you can load the values contained in
it to the string table (STRTABLE) using the TENTER command:

TENTER "UNIMENU.DEF


>this seems to be what I need to change...

Right.

>-----
>      GOES-9 Western Infrared
>F  5 "EG #?IFRMS;ALOOP #SYS(2113) #SYS(2114) #?IFRMS EC 32 130  -2 DWELL=#?DWE
> LL
>+ " MAP=YES H 9002 EU=IMAGE SU=IRTEMP LIMIT=12 BAR=#?BAR NO SF=YES
>------
>hmmm..? does every loop need to be $IFRMS long?

IFRMS stands for IR frame loops; VFRMS stands for VISible frame loops, etc.
See the listings in UNIMENU.DEF

>Thanks as always,

Later...

Tom