Hiding Outliner Window

filcole

Is there a programmatic way to turn OFF the outliner window?

I have a ruby script that is inserting many dynamic components. When each dynamic component is added Sketchup refreshes and redraws the Outliner view automatically, which causes the ruby script to run slowly. If the outliner winder is hidden then the script runs faster?

p.s. 1st post! Thanks for all the useful help on this forum.

thomthom

Welcome to the forum.

The Outliner is one of them damned curses a SU Ruby programmer encounters.

You have a command that works on PC: http://forums.sketchucation.com/viewtopic.php?f=180&t=23358&p=199303&hilit=outliner#p199107
But AFIK - no solution for Mac...

TIG

@filcole said:

Is there a programmatic way to turn OFF the outliner window?
I have a ruby script that is inserting many dynamic components. When each dynamic component is added Sketchup refreshes and redraws the Outliner view automatically, which causes the ruby script to run slowly. If the Outliner winder is hidden then the script runs faster?
p.s. 1st post! Thanks for all the useful help on this forum.

The Outliner is a known bug in SUp - Bugsplats can also happen - if the Outliner is 'rolled-up' the script will run faster and not crash [so much ]
This is the way I do it using Jim's PC only fix - sorry Mac users...
Add this code into a new ruby in /Plugins/ that will auto-load called toggleWindows.rb


### toggleWindows.rb - based on Jim's ideas - only for Windows...
### 20090401 TIG
### needs "Win32api.so"
if [PLATFORM].grep(/mswin/)==[PLATFORM] and Sketchup.find_support_file("Win32API.so","Plugins/")### = a Windows machine
  require 'Win32API.so'
  def toggleRollUp(name)
    findWindow = Win32API.new("user32.dll","FindWindow",['P','P'],'N')
    pw=findWindow.call(0,name)
    sendMessage = Win32API.new("user32.dll","SendMessage",['N','N','N','P'],'N')
    sendMessage.call(pw,0x00a1,2,"")#WM_NCLBUTTONDOWN
    sendMessage.call(pw,0x0202,0,"")#WM_LBUTTONUP
  end
  def isRolledUp(name)
    findWindow = Win32API.new("user32.dll","FindWindow",['P','P'],'N')
    getWindowRect= Win32API.new("user32.dll","GetWindowRect",['P','PP'],'N')
    pw=findWindow.call(0,name)
    data=Array.new.fill(0.chr,0..4*4).join
    getWindowRect.call(pw,data);
    rect=data.unpack("i*")
    #if window height is less than 90 then the window is rolledup
    return (rect[3]-rect[1])<90
  end
end#if

Add into your code this new test/defs


if [PLATFORM].grep(/mswin/)==[PLATFORM] and Sketchup.find_support_file("toggleWindows.rb","Plugins/")
### = a Windows machine and code is there...
  require 'toggleWindows.rb'
  def hideOutliner()
    $bOutlinerWasOpen= !isRolledUp("Outliner")
    toggleRollUp("Outliner")if $bOutlinerWasOpen
  end
  def restoreOutliner()
    toggleRollUp("Outliner")if $bOutlinerWasOpen
  end
end#if

Before the code runs add this into your code
hideOutliner()if [PLATFORM].grep(/mswin/)==[PLATFORM] and Sketchup.find_support_file("toggleWindows.rb","Plugins/")### = a Windows machine
To reset the Outliner as it was put this near the end of your code
restoreOutliner()if [PLATFORM].grep(/mswin/)==[PLATFORM] and Sketchup.find_support_file("toggleWindows.rb","Plugins/") ### = a Windows machine
Note that it also requires "Win32api.so" which I've attached in a zip file - unzip it into /Plugins/ folder...Win32API.zip

TIG

For Mac users there's probably an equivalent way = with AppleScript ? - but so far no one has come up with an idea...

Jim

Everything mentioned is correct for Sketchup versions prior to version 7. Afterwards, Sketchup.active_model.start_operation was modified to accept parameters to mitigate these problems.

A typical method I have seen to make a plug-in take advantage of the version 7 feature while remaining version 6 compatible follows:


if Sketchup.version.to_i < 7
  Sketchup.active_model.start_operation("Operation")
else
  Sketchup.active_model.start_operation("Operation", true)
end

thomthom

I knew that the second argument disabled the viewport from refreshing - but also the Outliner?

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