• 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. change default GUI callback

Stats

  • Locked Locked
  • Replies 17
  • Subscribers 149
  • Views 21932
  • 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

change default GUI callback

Leonid Y
Leonid Y over 13 years ago

Hello guys,

 I am a bit new to skill programming. I would like to change default behaviour of a standard form. Basically I would like one field to change its value when another field is modified in a default form. To be more specific, I want some exact values to be set in "Create Instance"  dialog for the "Delta X", "Delta Y" fields when a particular Lib Cell View is chosen.

I have found out that the form is bound to  the leCreateInstForm structure and it , in turns, has the fields: libName cellName viewName instName and so on; Each one has a list of properties including more interesting for me:

 _focusInCallback

 _modifyCallback

_callback

The values of first two properties are empty "" and the last one is set to

 "leInstCellNameCB(leCreateInstForm~>cellName~>value)"

which I suppose default skill routine which checks for cellview existence  in Library Manager and something else. I guess it is exactly where the things happen.

Till this moment everything seems to be clear, but when I replace  the default routine with my own one , which does just perfect when it is fed to CIW , it not only does not do what I expect but the whole mechanism seems to get broken till I restart icfb.

So, my questions :

- is it possible in general to change default behaviour in my case? some straight ways or tricky ones.

- what does the underscore  sign in the beginning of _callback property mean? There must be some special meaning..

  • Cancel
  • Leonid Y
    Leonid Y over 13 years ago

    I have managed to solve the problem with the piece of code below, please give me your opinion is this the right way to call some routine when Layout Editor being invoked?

     

    ;;;

    procedure(_defCR8I_CB(opt)
    leCreateInstForm->cellName->_callback="_cr8tinstCallback()"
    )


    deRegUserTriggers("maskLayout" '_defCR8I_CB)

     ;;;

    Also I had to introduce 1 argument to my function which is really not necessary for me but CIW issued a warning about missing arg and I added it. Can somebody clarify why is it so and what is the purpose of the arg?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 13 years ago

    The way you've done it is probably the way I'd have done it too...

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Leonid Y
    Leonid Y over 13 years ago

    It's good to know. Now I have implemented the functionality I needed. Thank you guys, I've learnt something new.

    The last thing I would like to clarify - what's the required argument for procedure which is used in deRegUserTriggers? In my case this is "opt" arg, without its definition CIW reports arg count mismatch error.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 13 years ago

    With deRegUserTriggers(), the first argument is required (the viewType), The 2nd to 4th arguments are optional, and default to nil. However, there is a check within the function to ensure that at least one non-nil argument has been passed (otherwise there's no point in calling it!), and it will error out if that's the case. You can (for example) call deRegUserTriggers("maskLayout" nil nil 'myPostInstallTrigger) and that would be OK - because the arguments are optional but positional, you need to pass nil for any argument you don't want to set - nil is the default in this case anyway (as can be seen from arglist('deRegUserTriggers) because you don't see any explicit default value for the optional arguments).

    Regards,

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Leonid Y
    Leonid Y over 13 years ago

    I must have stated it wrong way. My question is not about  the deRegUserTriggers() function itself but about function which is passed to it. In my case it is  _defCR8I_CB which does not require any arguments itself. Initially, I created it without any parameters and tried to pass it as it is:

     ;;;

    procedure(_defCR8I_CB()
    leCreateInstForm->cellName->_callback="_cr8tinstCallback()"
    )


    deRegUserTriggers("maskLayout" '_defCR8I_CB)

    ;;;;

     The commands worked OK but when tried to open any layout cellview CIW reported:

     

     *Error* _defCR8I_CB: too many arguments (0 expected, 1 given) - ((nil wasPushed nil prependList nil ... ))

     *WARNING* A Skill error occurred in function _defCR8I_CB

     

    That's why I had to define the redundant _defCR8I_CB(opt) parameter in order to avoid the error, but I do not really understand how it works.

     

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 13 years ago

    OK, the callback must be defined to accept a single argument. It's not optional as far as the caller is concerned. If you read the documentation on de triggers (in the manual which covers deRegUserTriggers amongst other things), you'll see that the argument is used to pass various information - for example, the window, the cellView, the action performed (e.g. whether you've pushed or popped, etc). It's a "disembodied property list". What it means however is that you must declare this argument in your function whether you need it or not - because it's going to be passed to you regardless.

    Many callbacks work this way - they have a documented call signature.

    Regards,

    Andrew.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Leonid Y
    Leonid Y over 13 years ago

    Good explanation, I got it. Thank you

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
<

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