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

Conference azur::mcc

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

5383.0. "Button already defined PROBLEM in Appliactions Launch." by KETJE::PACCO (Gallia divisa est in partes tres) Fri Jul 23 1993 10:58

    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.RTitleUserPersonal
Name
DateLines
5383.1Possible solution (?)COPCLU::SORENCS�ren H Christiansen - (7)857-2107Tue Oct 26 1993 12:1317
    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 :-)