automatically OK form from within skill code

I don't see why this wouldn't work:

hiRegTimer("hiFormDone(ICL_SYNCHRONIZE_FORM)" 1)

The problem is most likely that the form blocks the interpreter while it's up, so registering a timer to OK/close it should do the trick.  I have successfully used this technique on the impHdlOptionsFormMain ("Import Verilog" form).

I am mystified why you included checks for "ddsDBox" in your hiRegTimer call.

Also, there's little point bothering to check for the form's existence when you know you just opened it!

First of all, thank you so much for your prompt reply and help.  I see your point about the redundant check in my original code.  I copied it from Cadence Solution ID #11004818, and simply tried to make the appropriate form name replacements.

I just tried running two experiments, one with the original code I showed, and the other with your simplified line of code.  Neither method works when called from within the skill code;  they both yield the same behavior. When called from within the skill code, the form appears, but I have to manually click on "OK".

However, once again, when I simply copy and paste the three lines directly into the command interpreter window and execute from there, the desireable behavior is noted;  mainly, that the form shows up, stays there for 1/10 second, and then gets automatically "OK'd" and goes away:

dagDoNamedAction( dagNumToTool(3) dagGetObjectByPath( dagNumToTool(3) '( "ILBRootNode" "ILBRootClass"  "lib_test" "ILBLibraryClass" )) "Synchronize" )
hiiSetCurrentForm('ICL_SYNCHRONIZE_FORM)
hiRegTimer("hiFormDone(ICL_SYNCHRONIZE_FORM)" 1)

I don't know why it's not working, either.  I wonder if you might have any other ideas, theories, or experiments for me to try?  Thank you,

Geoff

Hi Geoff,

The order in which the code is run will be important - you need to 'schedule' a call to the SKILL to close the form before the form is posted. So possibly put the hiRegTimer() call before the hiiSetCurrentForm() call.  By the way, the latter is an internal undocumented SKILL procedure, you should probably be using hiSetCurrentForm().

I hope this helps.

Regards,

Lawrence.

 Hi Lawrence,

Thank you, changing the order seems to fix my problem!  The form now gets "OK"ed automatically.

Regarding hiSetCurrentForm, the only reason I'm using hiiSetCurrentForm is because that was what was reported in my CDSlog file when the form gets invoked.  Yes, it probably is some internal, and perhaps outdated script, but unfortunately I don't have any control over it (can't see the code), although I do need to run it.  When I try using hiSetCurrentForm instead, I get the following warning:

 \w *WARNING* hiSetCurrentForm: form is not displayed on the screen.

However, despite the warning, the desired results still seem to get obtained.

Again, thank you so much for your help;  this has been such a thorn in my side for the past few days!

Geoff

One more question, Lawrence.  Since I am "scheduling" the call prior to the form getting posted, does that mean that the timer interval doesn't start counting until the form gets posted, or does the timer interval start counting immediately when the hiRegTimer command is encountered?  I want to know whether I can specify:

   hiRegTimer("hiFormDone(ICL_SYNCHRONIZE_FORM)" 0)

without having to worry about theDone function "missing" the form.  Or must I enter an upper-bound best-guess estimate as to how much time it will take to invoke the form?

hiRegTimer

Description
Registers a SKILL function string that is executed after the specified time.
Arguments
t_callbackString SKILL function name (string) that is to be executed after the
specified time (x_tenthsofSeconds) has passed.
x_tenthsofSeconds Time, in tenths of seconds, after which the callback is executed.

wangge said:

must I enter an upper-bound best-guess estimate as to how much time it will take to invoke the form?

I've often wondered about this too....

The timer starts from when the toplevel responds - essentially when the event loop kicks in. Since that won't happen until after the form is mapped on the screen and it's completed the callback, using 0 should be fine.

Andrew.

Andrew Beckett said:

The timer starts from when the toplevel responds - essentially when the event loop kicks in. Since that won't happen until after the form is mapped on the screen and it's completed the callback, using 0 should be fine.

Since the delay is zero, could hiEnqueueCmd be used here?