[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

587.0. ".TYPE - not always?" by IRONIC::MINTZ (Mall Rat) Tue Apr 28 1992 17:51

    As I mentioned before, I'm part of the team updating the ALL-IN-1
    Application Programming I course.  
    
    Heavily embedded in the course is that *every* form *must* have a .TYPE
    specification.  However, it has been called to my attention that *not*
    every form does, in fact, have a .TYPE (new in V3.0?).   
    
    The forms that I've looked at without the .TYPE (located in CM) appear
    to have XOP options.  
    
    My question is this - how prevelant are these forms?  How/why are they
    used.  Are they referenced through a /MORE or .MORE or through some
    defined search order?  Is there a discussion on this anywhere in the
    doc set?
    
    And, finally, would it be "safe" to say (in the course) that ...nearly
    all forms have a .TYPE directive...
    
    Thanks in advance for your help.
    
    Audrey
T.RTitleUserPersonal
Name		DateLines
587.1context-sensitive menus?AIMTEC::WICKS_AThe Mancs will NEVER win the lgeTue Apr 28 1992 18:3118
    Audrey,
    
    As you say most (if not all) the ".TYPEless" forms are in CM and
    all the ones I've seen are related to context-sensitive menus
    which is of course itself undocumented - until Tony's new book hits
    the streets.
    
    I wouldn't even want to begin to attempt to explain context-sensitive
    menus in a note as it takes at least 2 hours to do in one of the
    classes run here at the CSC!
    
    Over to the experts for a 113 line explanation ....
    
    regards,
    
    Andrew.D.Wicks
587.2Looking for facts onlyIRONIC::MINTZMall RatTue Apr 28 1992 18:4510
    Andrew,
    
    Thanks for responding.  I have no intention in presenting ".TYPEless"
    (as you say) form processing in the course - documented or not.  I was
    just interested in the "facts" - and in making sure that what I "write"
    in the course is technically correct.
    
    Bye for now.
    
    audrey
587.3Nothing fancy, all legalCESARE::EIJSAll in 1 PieceWed Apr 29 1992 08:4745
    
    Audrey,
    
    The APR I, page 2-29 (V3.0 docset) indicates:
    
    ...The forms specified by /MORE do not have to be displayable forms.
    ALL-IN-1 treats them simply as storage locations for Named Data
    information....When a standard form is specified by /MORE that form's
    .TYPE directive is ignored...
    
    Indeed, the call to a form in CM can be context-sensitive. In your
    case, for almost every element type (FRM, DO, SCP, etc) a seperate form
    has been created which contains Named Data specific for an element
    type, and used for the options Print, Send, Read, Differences and GOLD
    GET. Also the Named Data for NEXT SCREEN (get me a template when
    creating an element) is included.
    So with one generic 'menu' form CM can access Named Data for processing
    of elements of different element types.
    
    E.g. When printing an element, you'll be put in the generic form
    CM$OPTIONS$INDEX$RPS:
    
    
    Form:    CM$OPTIONS$INDEX$RPS
    Library: VITARA$DKB200:[ALLIN1V30_DEV.LIB_ENGLISH]CM.FLB;
    --------------------------------------------------------------------------------
    
    ;;.TYPE;;
    
    INDEX/CHOICE=CHOICE/CLEAR/OVERLAY/MORE=#CM_OPT_MO
    /PRE='XOP "~~PRE~~"'/POST='XOP "~~POST~~"'
    
    
    Symbol #CM_OPT_MO contains the name of the form which contains the
    element type specific Named Data, e.g. CM$OPTIONS$FRM. This last form
    doesn't contain a .TYPE directive as it's only purpose is serving as a
    storage location for Named Data, so no .TYPE directive was used.
    
    Nothing fancy, but unusual compared to the other forms used in
    ALL-IN-1.
    
    Ciao,
    
    	Simon
587.5I'd include formset forms in the list, too...SANFAN::LESLIE_DAGreetings & SolutionsWed Apr 29 1992 16:150
587.6CM context-senstive menus a bad example?SIOG::T_REDMONDThoughts of an Idle MindThu Apr 30 1992 09:588
    One point I would make is that the CM context-sensitive menus are not a
    good example to use when creating your own application. An awful lot
    goes on behind the scenes, most of which lies cloaked in several layers
    of CM code (all script and named data, but still lurking in the
    depths).  Use a simpler example - like pages in form sets if you want
    to tell students about forms with no named data.
    
    Tony