Timing between deOpen and hiZoomIn

Hi, have you tried using hiEnqueueCmd which might solve your timing issues (I haven't tested it in your case)

Cheers

Aurélien

Hi, Aurélien! Thank you for your reply.

Do you mean the code as below?

procedure( tmp_zoom()
let((tmp_wid dbId)
    tmp_wid = deOpen(list(nil 'libName "my_lib" 'cellName "my_cell" 'viewName "my_view") nil "a" "" nil nil nil)
    dbId = car(geGetEditCellView(tmp_wid)->instances)
    hiEnqueueCmd("hiZoomIn(tmp_wid dbId->bBox)")
    hiEnqueueCmd("hiZoomWindowAtPoint(tmp_wid 0.9 centerBox(dbId->bBox))")
);let
);procedure

When I run the tmp_zoom command, tmp_wid is unbound variable because enqueued command may be executed after the tmp_zoom is finished and poped from the stack, I think.

Can the local variable be evaluated with hiEnqueuCmd?

You can use this CCStimer package which wraps around hiRegTimer (hiRegTimer with a time of 0 is equivalent to hiEnqueueCmd), which then allows you to pass a closure to be scheduled.

How to schedule a repeating function with a timer in SKILL

Put this function in a file with a .ils suffix to get SKILL++ lexical scoping, and ensure that CCStimer is loaded:

procedure( tmp_zoom()
let((tmp_wid dbId)
    tmp_wid = deOpen(list(nil 'libName "my_lib" 'cellName "my_cell" 'viewName "my_view") nil "a" "" nil nil nil)
    dbId = car(geGetEditCellView(tmp_wid)->instances)
    CCStimer->schedule(lambda((id) hiZoomIn(tmp_wid dbId->bBox)) 0)
    CCStimer->schedule(lambda((id) hiZoomWindowAtPoint(tmp_wid 0.9 centerBox(dbId->bBox))) 0)

);let
);procedure

I think that having the two zoomIn functions are causing a similar problem to the original geOpen timing issue. In essence geOpen was doing a zoom (the deOpen with the right arguments prevents that) and then a zoom afterwards was getting messed up; you're getting the same kind of problem by having two successive zooms.

Andrew

Hi, Andrew Beckett! Thank you for your reply.

It works perfectly when I set the timer for hiZoomIn 2 and hiZoomWindowAtPoint 3.

I really appreciate your help.

However, I'm still curious about the comment.

Andrew Beckett said:

In essence geOpen was doing a zoom (the deOpen with the right arguments prevents that)

Because when I wrote the function as below, the instance is still slightly off-center, and it is also not fit in the window.

(Successive zooms are removed and only a zoom is done after deOpen)

procedure( tmp_zoom()
let((tmp_wid dbId)
    tmp_wid = deOpen(list(nil 'libName "my_lib" 'cellName "my_cell" 'viewName "my_view") nil "a" "" nil nil nil)
    dbId = car(geGetEditCellView(tmp_wid)->instances)
    CCStimer->schedule(lambda((id) hiZoomIn(tmp_wid dbId->bBox)) 0)
);let
);procedure

This is why I created the post, asking about the timing between deOpen and hiZoomIn.

I understand that the geOpen followed by any zoom functions can cause the problem.

But I don't know why a zoom function is still get messed up when I use deOpen, rather than geOpen.

Deleting the last time you asked this in the thread and asking again is not going to get me to answer it more quickly. I've been rather busy the last couple of weeks (I'm sat in an airport as I type this) and I've simply had no time to reply. Deleting and reposting a question to "push it up the queue" is more likely to irritate me and just get the question ignored altogether... (obviously I didn't ignore it this time though other than having two emails to delete in my inbox)

I don't understand why you would have the problem with the code above which is using the CCStimer->schedule. I assume you're talking about the earlier version where you called hiZoomIn directly? I also didn't see the problem with deOpen with the nil as the final argument and just a single zoom. I have not any time (nor am I likely to have time) to investigate the details of the internals of the implementation to get to the root cause of the timing problem; I'm relying on the R&D engineer's explanation of the situation when this happened - which was either when there was a built-in zoom (which geOpen had) with a single extra zoom, or your case with deOpen which didn't do the zoom but then had two zooms and hence had the problem.

I also don't see why you would need non-zero delays - the two commands would be separately enqueued (I believe) and I think that ought to be OK with zero delay. I can't really investigate further though, sorry.

Andrew

Deleting the last time you asked this in the thread and asking again is not going to get me to answer it more quickly. I've been rather busy the last couple of weeks (I'm sat in an airport as I type this) and I've simply had no time to reply. Deleting and reposting a question to "push it up the queue" is more likely to irritate me and just get the question ignored altogether... (obviously I didn't ignore it this time though other than having two emails to delete in my inbox)

I don't understand why you would have the problem with the code above which is using the CCStimer->schedule. I assume you're talking about the earlier version where you called hiZoomIn directly? I also didn't see the problem with deOpen with the nil as the final argument and just a single zoom. I have not any time (nor am I likely to have time) to investigate the details of the internals of the implementation to get to the root cause of the timing problem; I'm relying on the R&D engineer's explanation of the situation when this happened - which was either when there was a built-in zoom (which geOpen had) with a single extra zoom, or your case with deOpen which didn't do the zoom but then had two zooms and hence had the problem.

I also don't see why you would need non-zero delays - the two commands would be separately enqueued (I believe) and I think that ought to be OK with zero delay. I can't really investigate further though, sorry.

Andrew

Oh, I'm really sorry to bother you and forum users.

I thought you'd missed my reply since there had been no reply about it for a week. I will not do it next time.

Again, I appreciate you and other forum users' help.