doEvents equivalent ?

I am executing a lengthier ruby script from a text file via eval() that has a couple of tasks to complete. At every task completion, I would like to bring up a QDialog with a few buttons and checkboxes etc. However, to pause and wait for the user to click "continue", I need to jump into some sort of a loop that does nothing but sleep. Unfortunately, sleep() occupies 100% of the main thread, so the loop always hangs up everything. VB has doEvents that checks for events that happened, and I can pop that into a loop and then it effectively lowers the execution priority of that looping thread. Does something like that exist in ruby/Klayout ?

Alternatively, a customized MessageBox may work nicely, because that halts the main thread. However, I can't seem to find a way of moving that to off to the side, like with setGeometry() for QDialog. Does anyone know how to do that ?

Thank you !



  • Hi Thomas,

    You should be able to execute a QDialog in a blocking ("modal") fashion by calling "exec" on the dialog. Did you try this?


  • I don't know when this was implemented but I noticed this only now. It just opened up a whole host of visual demo opportunities. It is not quite what I had asked to achieve in this thread, but it's worth pointing out.

     app = RBA::Application.instance
     app.process_events   # this is the VB::doEvents equivalent !!

    This allows the front-end main thread to execute while in a ruby script, meaning you can draw/move/erase/whatever and it does update whenever .process_events is called. I made an "Animate" QPushButton selection in your xSection package that turns off the progress bars, and instead inserts these .process_events at every xSectionGenerator::output. Now I can watch it live ! Of course, it comes at a cost of losing speed but it is darn good to look at !

  • Very good :)

    It's there already for some time. What you say it correct, but there needs to be a disclaimer here: using process_events excessively may lead to recursive event handling. So for example if you do process_events, some user might use a menu function which opens a modal dialog. This itself runs an event loop with the effect that your process_events will not return until the dialog is closed.

    Also, the user might interfere with what you're doing before and after "process_events" and the effect is often a program crash (e.g. if a shape you're working on is deleted). So while process_events runs the best advice is to keep hands off the edit functions.

    Instead of leaving this to the user, you can use "LayoutView#enable_edits(false)" on the LayoutView you're working on before and "LayoutView#enable_edits(true)" after your operation. This should block functions which would interfere with your actions (Caution: macros may still be active).


Sign In or Register to comment.