Hiding Outliner Window

Jim

I thought that was THE intended purpose, yes. It should keep all those "snappy"" dialog from refreshing.

thomthom

I thought THE purpose was to speed up script processing. I rarely have the Outliner open - but with that second argument, scripts that modify the model runs many times faster as each method that modifies the model doesn't wait for the screen to redraw.

But for whatever reason - it's great that it addresses both.

Jim

Right, it speeds up processing by not updating the dialog boxes. Without the 2nd argument, start_operation updates the dialog boxes on every line of Ruby code executed.

TIG

The second argument [a] in the model.start_operation(name,a,b,c) [there can be up to 4 !] if set true stops the User-Interface (UI) [= the SUp Window] from refreshing until there's a model.commit_operation - it SHOULD work on other SUp 'windows' too - like the Outliner - BUT I think that it doesn't do it properly [yet] - hence the clunky fix to roll-up any open Outliner Window, at least on PC, so that it's not interacting with scripted things like group or component making...

Jim

I think the UI means the toolbars, menus, and dialogs - everything but the drawing area.

And if the Outliner is updating during a script with the 2nd argument true, then I would consider that a bug.

TIG

@jim said:

I think the UI means the toolbars, menus, and dialogs - everything but the drawing area.
And if the Outliner is updating during a script with the 2nd argument true, then I would consider that a bug.

I manage to get it to work most of the time in v7 - with true the Outliner doesn't refresh till a commit - but it also stops the main window refreshing... so if you want to pause inside your script and see what you've drawn so far you need to commit then re-start an operation - resulting in possible multiple undo's later on - the transparency arguments seem too confusing too, as nesting start/commits seems flaky... If you miss a bit of code where there is intensive group creation then the Outliner can still crash SUp.

The roll-up script works OK on PC v6 and 7.

It IS best if the Outliner is closed when running intensive scripts - BUT users will be users...

thomthom

@tig said:

the transparency arguments seem too confusing too, as nesting start/commits seems flaky... If you miss a bit of code where there is intensive group creation then the Outliner can still crash SUp.

I believe they are broken...

Jim

Nesting start/commits has always been a no-no. I don't think the transparent nor the prev_trans arguments are related to nesting.

thomthom

@jim said:

Nesting start/commits has always been a no-no. I don't think the transparent nor the prev_trans arguments are related to nesting.

haven't tried to nest them. But making one commit transparent to the previous one - impossible...

Jim

The only way I know to pause a script is to use timers. I believe that is what Fredo does in plug-ins such as Round Corner which can be interrupted during long operations. You can call view.refresh (v 7.1+) to force a refresh of the view.

TIG

@jim said:

The only way I know to pause a script is to use timers. I believe that is what Fredo does in plug-ins such as Round Corner which can be interrupted during long operations. You can call view.refresh (v 7.1+) to force a refresh of the view.

You 'pause' a script so you can see the geometry so far by having start/commit operations that follow each other - unfortunately that means an undo for each operation... What we need is some way of group all of these into a 'nesting' operation that can be undone in one step ?

thomthom

@tig said:

You 'pause' a script so you can see the geometry so far by having start/commit operations that follow each other - unfortunately that means an undo for each operation... What we need is some way of group all of these into a 'nesting' operation that can be undone in one step ?

That's what the third and fourth argument in .start_operation is meant for. If only they where working...

Jim

@tig said:

You 'pause' a script so you can see the geometry so far by having start/commit operations that follow each other

This is not a requirement for updating the view. There are other ways to do it.

I have not tried it in awhile, but I seem to remember a messagebox will pause the program and the view will be updated. Or maybe calling view.refresh followed by sleep(2) might work. I mean, if your goal is to pause the program just to see it's progress.

fredo6

@tig said:

@jim said:

The only way I know to pause a script is to use timers. I believe that is what Fredo does in plug-ins such as Round Corner which can be interrupted during long operations. You can call view.refresh (v 7.1+) to force a refresh of the view.

You 'pause' a script so you can see the geometry so far by having start/commit operations that follow each other - unfortunately that means an undo for each operation... What we need is some way of group all of these into a 'nesting' operation that can be undone in one step ?

You don't need the extra arguments and can do all geometry within a single Start - Commit operation.
Just give back control to the Tool by encapsulating the geometry construction in timers.

Fredo

TIG

@jim said:

@tig said:

You 'pause' a script so you can see the geometry so far by having start/commit operations that follow each other

This is not a requirement for updating the view. There are other ways to do it.
I have not tried it in a while, but I seem to remember a messagebox will pause the program and the view will be updated. Or maybe calling view.refresh followed by sleep(2) might work. I mean, if your goal is to pause the program just to see it's progress.

A messagebox will cause a window to redraw IF the start_operation argument is false - but if it's true the window's contents are unchanged until the commit arrives.
view.refresh should work with the operation BUT it IS limited to very recent SUp versions, so cannot be backwardly compatible. To such make a script v6 compatible would mean convoluted version checking...
view.invalidate waits for the commit.

Dan Rathbun

At the end of the operation, does SU update the UI automatically?

or, is it a good idea (just to be sure) to call:
UI.refresh_inspectors # force complete UI update
http://code.google.com/apis/sketchup/docs/releases.html

thomthom

In my experience SU seem to update the viewport after commit_operation.

But if an error occurs before your [ruby]commit_operation[/ruby - then the viewport won't update until you pan/orbin/draw.

filcole

Hi Tig (and all others),

Thanks for the responses, fixed my problem wonderfully. Kudos.

I did try using start_operation() with the second parameter set to true, but the Outliner window is still redrawn when each dynamic component is redraw using $dc_observers.get_latest_class.redraw_with_undo(compInst).