Running 2 procedures or function in 1 bindkey

Hi,

I preference for such cases would be to use hiReplayFile(). There is also hiEnqueueCmd() which I'm not familiar with much

-Ramakrishnan

Hi,

Most likely the form is blocking, so as soon as it is displayed the code afterwards (applying the form callback) doesn't get executed. I think that Ramakrishnan may be correct in that you can use hiEnqueueCmd():

hiSetBindKey("Schematics" "<Key>F12" "hiEnqueueCmd(\"_hiFormApplyCB(xcreateNetlistForm)\") xcreateNetlist()")

However, it is often better to look for an API that is not dependent on the form/GUI - can you investigate what the form callback is and see if you can call that directly? [You may not be able to do this if the callback depends on the form structure and the values collected there].

Best regards,

Lawrence.

Thank you much Lawrence. Solution you provided is working. 

On side note, how do I find out form callback ? I may need this for my other work.

Hi Gunavant

You may use the following trick to get the callback in a form.

1. Call out the form.
2. use command "form1 = hiGetCurrentForm()", to fetch the object for the form.
3. check the property of the form, simply by "~>" operator, like "form1~>?"
4. "_doneAction" indicates the callback function for "Apply" or "OK", like "form1~>_doneAction"
5. if you visited a "field" of the form, you will see the "_callback" property of it, like "form1~>field1~>_callback"

Best Regards

Yi

Hi,

This is good but I have one small correction: the ~> operator should be used with database objects such as cellview id's, object id's, tech file id's, rod objects and so on, whereas the -> operator should be used with things like menu structures, form structures, window id's, disembodied property lists, tables and so on (essentially "anything else"). One benefit of the ~> operator is that it can accept a list of objects on its left-hand-side and can apply the same query to each of those objects in turn, collecting the results of each into the resultant list.  So in your example the ~> should ideally be changed to -> (it will still work).  I reserve the use of "~>" when dealing with db objects as noted earlier.

Cheers,

Lawrence.

Hi Lawrence,

<pedantryAlert>

Whilst I tend to follow the convention you suggest (although generally speaking I write in LISP syntax rather than using operators at all, as you know), strictly speaking the only difference between ~> and -> is when the left-hand-side is a list.

If the left-hand-side is a singleton object, they are equivalent. If the left-hand-side is a list, then -> treats the list as a disembodied property list; the ~> operator does an implicit "foreach mapcar" across the list - so in other words if you do theList~>prop it will return a list of all the resulting values that you'd get if you did ~>prop for each member of the list.

</pedantryAlert>

Regards,

Andrew.

Hi Andrew and Laurence

Thank you for giving the insight of "~>" and "->". It's very helpful.

I use "~>" more often, as when I read the "User Guide", it mentioned "~>" as generalization of "->".

And during practice, I found "~>" is easier to use (works at most of the situations)

I just try both of them on a disembodied proper list, and recall my memory that I use "->" for the DPL in the past, as "~>" fails.

And with your explanation, I have a further understanding of the error message and why "~>" fails. Thanks again.

Best Regards

Yi