Set_status_text

A few years back set_status_text stopped working in LightUp while its building geometry and the process takes a few seconds. For 10+ years prior it worked just fine but I think around the time the Trimble engineering refactored to run the window/display in a separate thread perhaps(?), it doesn’t update until your Tool returns from the UI::Command block its executing.

Before I dive into Qt + Windows messages and bend this to my will to make it work:

  1. Has anyone else seen something similar?

  2. Is there a way of forcing the SketchUp window to repaint? I’ve tried sleeping for 10ms (ie yield to another thread), invoking View#invalidate with no success.

(FYI: Its not to do with start_commit disable_UI)

The first thing I’d try is Sketchup::focus

There are also:

Another thing to try when statements get blocked is to wrap them in a timer block:

UI.start_timer(0, false) { Sketchup.status_text= "Generating geometry ..." }

Where are you making the call, from inside the command block or from within a tool callback?

There is view.refresh which forces an immediate invalidation of the viewport and thus a drawing of the view.

However, the status bar seems to be handled differently and should update with tool#set_status_text, except when you are in the middle of a long calculation.

It is unclear however, because it used to work in the past, when I was using a cheap progress bar but doing putsof ‘.’ to show the progression (I now use a true progress bar and slice the long calculation into small chunks to give back control to view.refresh).

Since the migration to Qt (SU2023 on Windows) and the subsequent releases, there has been impact on the refreshing of the viewport. For instance, in SU2026, puts seems to be sligthly asynchronous so that the view may refresh.

There is nothing documented, so any behavior can change in any next release.

FYI, there is no Tool#set_status_text method. It is a method of the Sketchup module.

As I recall, the status bar seems to be updated whenever the mouse moves. Setting it’s text can be done in Tool#onMouseMove or in the tool’s #draw method.

My mistake, I shoudl have written Sketchup.set_status_text

When you are within an active Tool, you can call it wherever you want, for instance within a calculation loop, regardless of whether you move the mouse or refresh the view. In principle in should update on the screen, except that if the calclation is long and intensive it does not.

2 Likes

No, its not a focus thing, the Sketchup window is the active window.
Its as if the redraw code is just never invoked.

Agreed. The reality is it does not work great and there is almost no documentation as to what the “limits of use” are. As I said, sure, I can reverse engineer anything - I just wish I didn’t have to.

Is there anyone on Trimble team who could shed some light on “How do to make the status bar redraw”?

I thot it was worth a try. If it worked it again would be non-documented.

Did the timer pattern work at all?

Did you try during any tool callbacks?


ping @CraigTrickett

Didn’t work - and honestly, I really dont want to descend into having N asyncronous timers firing off.

I have a Tool that when selected, processes the geometry and begins rendering. It continues until another Tool is selected. Surely that is a use-case that the SketchUp status bar can handle, right?

1 Like

Okay, you never specifically answered whether you tried updating the status bar in the tool’s draw() method or onMouseMove() callback.

We would hope so because basically the status bar belongs to the active tool.
But progress indicators have been a P.I.T.B. for extension coders.

REF API Feature Request going on seven years old:

Dan, there is no drawing or onMouseMove during processing. I used to show progress in the status bar by calling set_status_text from within the C++ processing - which worked fine. Now it doesn’t.

And yes, this is essentially a progress bar.

I can’t remember the details on the top of my head but I have had issues with setting statusbar text outside of my tool as SketchUp updated it right after. I used a 0 timer as a workaround to make sure mine was the last to be set and at least back then it worked.

That said, it’s quite hacky. I’m not sure if statusbar texts are even expected to be set outside of a custom tool.

So, you are thinking something changed from SU2023 and later under Qt framework?

This test tool works fine (in 2026.1) as Sketchup.set_status_text() is called directly from the instance methods of a active Ruby tool object.

CursorTestTool.rb (1.4 KB)

This might indicate that the API is checking the call stack to decide whether to honor the method call to set the status bar text.

So a workaround could be to have the C-side change the progress text held in an instance variable and then call an instance method of the tool that displays the progress text by directly calling Sketchup.set_status_text from within that method.

FYI, sorry I now realize it was onSetCursor() that is called whenever the mouse moves.

Yes quite hacky. Just to be super clear, this is not calling set_status_text() outside of a Tool. The UI:::Command block is just:

{ LMap.render() }

Inside LMap.render() there are calls to set_status_text(). It should work.

EXCEPT, that a UI::Command object is NOT an abstract Sketchup::Tool object, so no the assumption that it should work from a command block is incorrect, if the engine is checking the callstack (or by some other means) to determine that the call is truely being made from within the current active tool.