Code behaves differently when Ruby Console is open

I have a fairly complex script that can run for a long time processing all the components in a model. It’s broken up into three start_operation / commit_operation blocks to increase performance by not updating the UI. I find that it refreshes the UI about as much as expected if the ruby console is open, but if it’s not, there are no UI updates at all. The end result of the script is still correct, but the user is left with little feedback while the processing takes place. Is it expected that the behavior is dependent on the ruby console being open?

SU24 / Windows 11

I would say not. But are you sending IO output to the console?

How are you showing feedback to the user? (Ie, I would argue that the Ruby Console is not meant to be used to show user feedback. I have instead made a non-modal HTML dialog and sent text to it to be appended or replaced.)

What is your expectation ?


Other coders have seen some delay and random order of output to the 24.0 console.

I know @Fredo6 and @Whaat have noticed this.

Definitely, the Ruby console is influenced or influences the rest of Sketchup, probably because it is written with the high-level framework Qt. I wished it stayed as a OS native window…

When you do a puts to the console, it kind of trigger a refresh of some visual elements, because of the asynchonous nature of the dialogs.

In your case, if you have long operations, I suggest you break them into small chunks and use a timer to give back control to Sketchup for UI update. Then, you can design a progress bar or write in the Status bar, or display a visual for waiting.

1 Like

Yes, I’m sending debug info to the console, but not expecting the user to look at it. I do use Sketchup.status_text, but that does not seem to get updated either unless the console is open.

I broke it up into smaller pieces, because I need to undo my changes at the end, and one of the steps is an explode. It’s been discussed in another thread that undo-ing an explode makes Sketchup unstable, and will crash shortly after. So my expectation was to see the result after each step when I do the commit. That seems to happen when the console is open, but nothing at all if it’s not.

I would at least like to give the user some idea that the script is still running and hasn’t died. The non-modal dialog is an interesting idea. Seems that could be encapsulated in its own class very neatly. Thanks for the idea.

Thanks Fredo. Can you elaborate on “use a timer to give back control to Sketchup for UI update”?

I would agree unless the operations are linked together.

Yes, … weird.

The status text easily gets wiped out if the mouse is moved and it is not your tool controlling it.

Perhaps this would be a good use for 2D Overlay text ?

See the old EditFlag extension for an example. It still uses the UI::WebDialog class as it is 10 years old and came 4 years before SU2017 and the UI::HtmlDialog class.

Edit Flag Plugin 2024 - #14 by DanRathbun

I’ve been contemplating updating it for either the UI::HtmlDialog or an Overlay instead.

We have been having issues with trying to implement a Progress dialog that works.

The Ruby Console affects whether it does or does not go “Not Responding”.
It also sometimes needs to have output to $stdout (which is SketchUp’s console.)

See this other topic:


UPDATE: In the past few days, testing a progress overlay, I have found that (on Windows) the SketchUp application goes into “Not Responding” mode unless both the Ruby Console is open and text is output periodically to $stdout (which is redirected to the SKETCHUP_CONSOLE object,) within the timeout for PeekMessage which is ~4-5 seconds.