[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

66.0. "Menus and form preprocessing" by MARVA1::RCOLLINS () Thu Feb 20 1992 16:50

	I am working on a dynamic Menu solution for a customer.  When I take
	the approach recommended in note ALL-IN-1_V24 #2666.6 I encounter
	a problem when the dynamic menu calls any form with a /PRE_FUNCTION,
	specifically another menu.

	The call to the menu form with the /PRE takes place as follows:

		(From the dynamic menu form)
		;;.RETURN;;

		.IF ... THEN GET OA$FUNCTION = "FORM EMC" 

		(EMC is used here only has an example.)

	The first time EMC is called the form is displayed correctly with
	all the fields filled in that are filled in during pre-processing.
	Any subsequent call to EMC via the dynamic menu and the fields that
  	are filled in during pre-processing remain blank.  Further 
	investigation shows that no pre-processing is performed.

	Why not? 

        I have moved the call to /POST on the CHOICE field with the same
	results.  Of course, if the call takes place is the pick processing
	(i.e. ;;EM;;) then it works correctly.

	What are the chances that there is some undocumented feature of FMS
        that would provide  the following functinality:

		;;??;;

		(Process for any entered value in choice not defined
                 on this form.)


	Thanks!
	...Ray
T.RTitleUserPersonal
Name		DateLines
66.1Standard wizardry, reallyA1VAX::BARTHBridge-o-matic does it again!Fri Feb 21 1992 14:5020
>
>	What are the chances that there is some undocumented feature of FMS
>        that would provide  the following functinality:
>
>		;;??;;
>
>		(Process for any entered value in choice not defined
>                 on this form.)

Nil.  First the nitty answer:  it would be an undocumented feature of ALL-IN-1.
FMS doesn't do any Named Data processing.

Here is an alternative.  In your ".RETURN" processing, if you discover
that the choice is blank/invalid/"other"/special then 
GET CHOICE = "your special something"  (YSS)

Then ALL-IN-1 will do the Named Data for ;;YSS;; as normal menu processing.
This should provide all the processing you are trying to get.

K.
66.2Check if OA$FLD_DONE is there.CESARE::EIJSAll in 1 PieceFri Feb 21 1992 15:2213
    
    Ray,
    
    Check if there is a OA$FLD_DONE as (one of the) last lines in your
    ;;.RETURN;; code. It solved your problem on my system.
    
    Karl's explanation is basically how CM handles it dynamic menus in
    ALL-IN-1 V3.0, only an additional dataset has been put in between, a
    dataset defining which XOP should be called at which menu option.
    
    Ciao,
    
    	Simon
66.3MARVA1::RCOLLINSFri Feb 21 1992 16:1238
I know that .1's solution would work, and in the original design that
was how I had planned it.  However, that is unacceptable by the customer. For
whatever reason the customer does not want to define all the possible choices
in name data of any menu. 

I have a solution that works but the customer has a problem with that too.

A simplified version of the solution looks like this:

;;CHOICE;;

/POST = 'GET #choice = choice\
         GET #name_data = name_data.name_data[#choice]\
         .IF #name_data NES "" THEN GET choice = "__"'

;;__;;

  GET choice = #choice
\ GET OA$FUNCTION = #name_data

The seems to work fine.  However the customer doesn't like the fact that
the user sees the substitution of the value in choice on the screen.

To get around this problem I tried to impliment the solution described in
note ALL-IN-1_V24 #2666.6.  A simplified version of that looks something like:

;;.RETURN;;

GET #name_data = name_data.name_data[choice]
\ .IF #name_data NES ""
   THEN GET choice = ""
   \\   GET OA$FUNCTION = #name_data

This would work, the choice field is blank out, but with the screen being
overlayed the user propable wouldn't notice.
    
And this is where I run into the problem with preprocessing described in .0.
66.4Sorry, see .-2)CESARE::EIJSAll in 1 PieceFri Feb 21 1992 18:5421
    
    Hi Ray,
    
    Apart from the solution, redefining the ;;.RETURN;; is OK, but in the
    end it should still act like a RETURN (meaning OA$FLD_DONE). The
    following worked for me (I just skipped the NAME_DATA form):
    
    ;;.RETURN;;
    
    GET #name_data = "FORM CM$MAIN"
    \ .IF #name_data NES ""
       THEN GET choice = ""
       \\   GET OA$FUNCTION = #name_data
    \OA$FLD_DONE
    
    Ciao,
    
    	Simon
    
    PS I'm starting to feel I'm missing something...
66.5If not ok from .4, try a CLOSE_PRIOROSLACT::EVEN_PLars Even Christiansen @NWO, DS/IS OsloFri Feb 28 1992 11:019
Hi,

It's a long shot as I'm not familiar with dynamic menus, but maybe a 
CLOSE_PRIOR after the call to the other MENU form would help, i.e something
like this:

	.IF ... THEN GET OA$FUNCTION = "FORM yourmenuform\CLOSE_PRIOR"

L'Even.