| Title: | DECmcc user notes file. Does not replace IPMT. | 
| Notice: | Use IPMT for problems. Newsletter location in note 6187 | 
| Moderator: | TAEC::BEROUD | 
| Created: | Mon Aug 21 1989 | 
| Last Modified: | Wed Jun 04 1997 | 
| Last Successful Update: | Fri Jun 06 1997 | 
| Number of topics: | 6497 | 
| Total number of notes: | 27359 | 
    I am trying to use the Application Launch Facility extensively
    but get often the following message:
    
    
    Aborting <filename>.def processing. Button <button_name> already defined.
    
    
    1).
    In fact this text is ONLY displayed when I exit from the ICONIC MAP.
    As long as I am staying in the map no message appears, but I am missing
    al lot of applications.
    It took me 1 1/2 days to understand this behaviour.  Also it is not
    possible to be sure ALL applications were integrated because of this.
    
    
    2).
    I am trying to define Submenus and Buttons.
    I am very conscious that I have to choose different button names within
    a submenu, but I expected "according the context in which the button
    applies".
    It seems that if the same button is already used in the same
    Menu/Submenu the application is not integrated.  Even worser,
    a lot of applications which have nothing to do with that problem, also
    does not show up any more under their appropriate Menu.
    
    e.g.
    Menu:  Operations
        Button:     Login
            binary:     ologin
            argument:   <Node.!.Name>
            env_type:   TERMINAL
            term_title: OSI login
            icon_label: Login
            applies_to: node
    Endmenu:
    
    is in conflict with
    
    Menu:  Operations
            Button:     Login
                binary:     telnet
                argument:   <InternetAddress>
                env_type:   TERMINAL
                term_title: TELNET login
                icon_label: Login
                applies_to: snmp
        Endmenu:
    
    because "Login" = "Login" although the contect in which it applies
    is completely different.
    ------------------------------------------------------------------
    
    If I use:
    
    Menu:  Operations
        Button:     Login
            binary:     /usr/.../gen_login
            argument:   *<Node.!.Name>* *<InternetAddress>*
            env_type:   TERMINAL
            term_title: Remote login
            icon_label: Login
            applies_to: node,snmp
    Endmenu:
    
    With this I get the message "AttributeArgument is not valid with verb
    and entity" when clicking on an IP entity, 
    and I get
    Exception: Invalid memory address (dce / thd)
    when clicking on a node entity.
       
    DOES THE ARCHITERTURE RESTRICTS THE USE OF BUTTONS IN THIS WAY?
    I AM VERY UNHAPPY WITH THESE RESTRICTIONS.  THIS MAKES APPLICATION
    INTEGRATION VERY DIFFICULT.
        
    Is there any way to work around these 2 problems, in this or a future
    version of DECmcc ?  For question 2. is it possible to "apply" to
    different entities/subentities, but have the entity name (chain of names)
    got back depending the applies_to context ?  How would you propose to
    solve this "Login" dilemma?
    
    	Regards,
    	Dominique.
    
    
    
| T.R | Title | User | Personal Name | Date | Lines | 
|---|---|---|---|---|---|
| 5383.1 | Possible solution (?) | COPCLU::SORENC | S�ren H Christiansen - (7)857-2107 | Tue Oct 26 1993 12:13 | 17 | 
|     Hi,
    
    We saw the same error message at Netman (joint-venture between DEC and
    NKT Elektronik (danish vendor of telecom equipment)), and we believe
    we have found the reason for and the solution to the problem. The
    Application Launcher first searches the home directory of the user 
    for mcc_appl_xxxx.def files, and next the directory pointed to by 
    the MCC_APPL_SYS_LOCATION environment variable.
    In our case, the environment variable was set to point to the home
    directory of the user, causing the application launcher to read the
    mcc_appl_xxx.def files twice! The solution is either to store the
    mcc_appl_xxx.def files in a separate directory, or not to use the
    MCC_APPL_SYS_LOCATION variable.
    
    Rgds,
    
    Soren :-)
 | |||||