WD's, Long Ops, Cancel, better sample


To all,

Sorry about the previous post, I was changing the structure in my code, and was ‘distracted.’

Attached is a good sample of the code for a Web Dialog progress bar with a cancel button.

It uses Javascript setTimeout in each ‘update’ loop, which seems to have a minimum time of about 15 mS.

Hence, it will add time to a long loop if you update the progress bar too often.

It uses threads for SU8 & SU2013, and fibers for SU2014 +. Interestingly, if I force it to use Threads for 2014+, it BugSplats SU.

Just run/load from the Ruby console…

To use in your own code, your ‘long operation’ code needs to be passed in the setLoadProc_Cancel call.


ProgressBar.rb (8.7 KB)


I’m not trying to be a moron, but, just to mention what Dave Thomas wrote in the Pickaxe book: always use snake case in ruby.


@MSP_Greg, did you test the code?

do you have a gif of it in action?

Error: #<FiberError: fiber called across stack rewinding barrier>
<main>:41:in `resume'
<main>:41:in `block in initialize'
<main>:274:in `call'
<main>:274:in `messagebox'
<main>:274:in `runPB'
<main>:306:in `<main>'
SketchUp:1:in `eval'

then it just seems to be an infinite loop of UI.messagebox’s…




I tested the code in Windows, with SU 8, 2013, and 2014. I won’t have access to a SU 2015 for a few days. Not sure about Apple OS’s.

I believe that code blocking on show_modal, execute_script, and JS callbacks is somewhat different when using Windows or Apple…

You should be able to click no to any of the UI.messageboxes.

I set the code up that way since some Thread operations have been known to have intermittent issues; one could run it several times.

I’ll look into that error message and see if I can determine what’s happening…

Thanks for testing it,



Yes. Unless you specifically accounted for the differences and tested on Mac, this is very likely the cause.


in my version, I abandoned threads [because I couldn’t get them to work on PC’s…]

I also never thought to add the cancel button…



John & SL,

I knew that on Apples, show_modal did not block, but didn’t think about the problem that would cause, which is the continuing UI.messageboxes in the original code.

I’ve updated the first post with new code that runs from the WD and removed the UI.messagebox.

Hence, on an Apple, the main thread hits a ‘waiting for the UI’ state when show_modal is executed. IOW, I’d appreciate it if you could test it again on a Mac…