[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1936.0. "Named data is invoked late." by HOTAIR::MADDOX (Politicians say the darnedest things) Wed Dec 09 1992 20:09

    This has probably been addressed before, but I couldn't find it.
    
    I have one menu form which invokes another menu via named data.  The
    problem is that the named data on the called form is not invoked until
    the named data which follows the FORM function.  How do I force the
    named data on the called form to be dispatched before proceeding in the
    original form.
    
    Ex.:
    
    ;;OPT;;
    
    form SECOND_MENU\
    compute #COUNT = #COUNT + 1
    
    
    Second menu:
    
    ;;OPT2;;
    
    get #COUNT = 0
    
    The result has #COUNT equal to 0.  A trace shows that the COMPUTE
    function was invoked before the GET function.
    
    Oh, yes.  This is ALL-IN-1 2.4
    
    Thanks,
    
    Joe
T.RTitleUserPersonal
Name		DateLines
1936.1What about an 'ARG' type form?CESARE::EIJSAll in 1 PieceThu Dec 10 1992 07:5315
    
    Hi Joe,
    
    > ...that the named data on the called form is not invoked until the
    > named data which follows the FORM function
    
    This is the case if the form called is a MENU type form. If you change
    the form type to ARG it will do what you want. However, it not being a
    MENU form any longer the form has to take care of processing the CHOICE
    input, check if it's a valid 'menu' entry and call the associated code
    for the option.
    
    Ciao,
    
    	Simon
1936.2Then can you explain this?HOTAIR::MADDOXPoliticians say the darnedest thingsThu Dec 10 1992 15:5816
    Simon,
    
    Thanks!  I was afraid this might be the answer.  Can you (or anyone
    else) offer any explanation as to why this logic works from an index
    menu?  I call exactly the same menu from named data associated with a
    OA$_MO_X_READ option and it works fine.
    
    All the called menu does is let the user specify whether he wants a 
    Brief or Full description displayed or printed.  The menu just sets a 
    symbol based on which option the user selects.  The reason I elected 
    to user a menu instead of an argument form was to preserve the menu 
    behavior.
    
    Thanks,
    
    Joe
1936.3Try a OA$MENU_LEVEL_PUSHHVNBND::WARFORDRichard Warford @CEO DTN 367-5455Thu Dec 10 1992 18:5610
    ALL-IN-1 only lets one menu be active at a time. When you call the
    FORM function and it is a menu, it just puts the menu name on the
    stack. When it comes time to ask for user input (for a menu choice)
    it activates the menu on the top of the stack.
    
    You may be able to force it to process the menu when you want using
    the OA$MENU_LEVEL_PUSH function. This starts a new stack - so it
    won't think its in the middle of processing the current menu.
    
    Rick
1936.4.2 - theoryIOSG::SHOVEDave Shove -- REO2-G/M6Fri Dec 11 1992 09:326
    Could it be because Index forms aren't menus (they're .TYPE INDEX).
    
    I'm not an expert on how this part of the product works, but there
    could be difference in processing.
    
    Dave.