• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. How to Unregister a custom Menu using deUnRegUserTriggers...

Stats

  • Locked Locked
  • Replies 9
  • Subscribers 143
  • Views 17443
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to Unregister a custom Menu using deUnRegUserTriggers()

jaleco
jaleco over 12 years ago

Referencing an old post by Andrew Beckett, (Andrew if you could please clarify how to do this)

http://www.cadence.com/forums/p/17476/1245483.aspx#1245483

I am trying to build a menu which includes a menu item to re-load the menu.

The purpose is for adding new items and for testing and debugging code, without having to close Cadence and re-start.

Per Andrew's post, the Banner Menu should not be added in a Post Install Trigger (which appears to be the standard method), so I am loading it as (one of) a list of menus to add as a userMenuTrigger passed to RegUserTriggers.

I have not found a way to successfully do this.  Cadence will not reload UserTriggers without deleting them first, and cannot delete selectively, so all get deleted and all have to be re-registered.  What this means is that my "list" of menus has been expanded from the one custom menu, to include others not defined in the Menu.il file.

Another problem is that in order to re-load the modified menu in-session, I have to first delete it.

hiDeleteMenu() requires an argument of "r" type template, a defstruct which I can't locate.  Defining the Menu does not return any value to the CIW, so I do not know what the argument is that needs to be passed to hiDeleteMenu().

I have tried modifying this code many times.  Even when I do not get an Error message, the Menu does not get updated with the current code instructions.

Here is some sample code:

procedure(MyMenu(args)

let((Update)

; define menu item(s)

  Update = hiCreateMenuItem(

  ?name  'Update

  ?itemText  "Update"

  ?callback  "call_Update()"

) ;Update

; define call procedure

procedure( call_Update()

  load("MyMenu.il")

) ; proc

; create pulldown menu

if(boundp('MyMenu) then

hiDeleteMenu('MyMenu)

) ; fi

list(OtherMenu hiCreatePulldownMenu(

  'MyMenu

  "MyMenu"

  list(Update)

 ) ; list

) ; let

) ; proc

; trigger menu

if ( ( deGetAppInfo( "maskLayout" )->userMenuTrigger ) then

; this always returns true because MyMenu is not the only user Trigger Menu!!

; can the test case be more specific for MyMenu??

 deUnRegUserTriggers("maskLayout")

; this removes ALL user Trigger Menus

deRegUserTriggers("maskLayout" nil 'MyMenu)

else

 deRegUserTriggers("maskLayout" nil 'MyMenu)

) ; fi

 

- James C.

  • Cancel
Parents
  • jaleco
    jaleco over 12 years ago

    FYI, regarding the deInstallApp() calls...

    the initial open of a layout cell view does have several "Loading... .cxt" transcript messages, and

    the first call to Update() from the menu, does show "Loading pCellGen.cxt" in the CIW transcript.

    Following these initial actions, once the relevant .cxt files have been loaded, they do not need to be reloaded, so nothing is reflected in the CIW transcript.

    My own suppositions.

    - James

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • jaleco
    jaleco over 12 years ago

    FYI, regarding the deInstallApp() calls...

    the initial open of a layout cell view does have several "Loading... .cxt" transcript messages, and

    the first call to Update() from the menu, does show "Loading pCellGen.cxt" in the CIW transcript.

    Following these initial actions, once the relevant .cxt files have been loaded, they do not need to be reloaded, so nothing is reflected in the CIW transcript.

    My own suppositions.

    - James

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information