Getting and iterating scene list?

thomthom

Doesn't sleep freeze up SketchUp itself?

thomthom

@thomthom said:

Doesn't sleep freeze up SketchUp itself?

Yes it does.

puts 'foo'; Kernel.sleep(5); puts 'bar';
SketchUp doesn't respond at all until sleep is over.

Dan Rathbun

@thomthom said:

Doesn't sleep freeze up SketchUp itself?

It should not freeze the C++ side, which should continue animating or zooming the camera. It should only pause the Ruby interpreter.

And I likely showed more time than is needed in at least the first place in the example. The second place is dependent upon how many pages need updating thumbnails, etc.

Dan Rathbun

@thomthom said:

@thomthom said:

Doesn't sleep freeze up SketchUp itself?

Yes it does.

puts 'foo'; Kernel.sleep(5); puts 'bar';
SketchUp doesn't respond at all until sleep is over.

Apples and Oranges.

puts is on the ruby side, ... of course sleep will pause between the two Ruby statements!

thomthom

@dan rathbun said:

@thomthom said:

@thomthom said:

Doesn't sleep freeze up SketchUp itself?

Yes it does.

puts 'foo'; Kernel.sleep(5); puts 'bar';
SketchUp doesn't respond at all until sleep is over.

Apples and Oranges.

puts is on the ruby side, ... of course sleep will pause between the two Ruby statements!

I should have been more specific - I cannot interact with SketchUp until sleep is over. The puts statements where just visual clues to know when it was over.

thomthom

@dan rathbun said:

@thomthom said:

Doesn't sleep freeze up SketchUp itself?

It should not freeze the C++ side, which should continue animating or zooming the camera. It should only pause the Ruby interpreter.

You didn't test it, did you?

Dan Rathbun

It's probably not perfect,.. and I did say this:

@dan rathbun said:

If this does not work correctly.. then we'll have to implement a FrameChangeObserver.

I'd likely use a UI.start_timer block along with a FrameChangeObserver if the sleep did actually interfer (perhaps SketchUp cannot call ViewObserver or PageObserver instances during sleep call ??)

So.. you could be correct Thomas. This the ol' workaround thingummy again. I wish the API would finish doing certain things, before returning a value from many API method calls (like setting pages, etc.)

Dan Rathbun

@thomthom said:

You didn't test it, did you?

Nope.. caught me!

I just whacked it out.

I'll have to drink another cup of coffee, and put in a FrameChangeObserver

thomthom

Rember, we cannot even use Ruby threads without blocking SketchUp. And wouldnt it be difficult for the Ruby engine to interact with the SketchUp engine and the entities if they ran in a separate thread/process?

HPW

OK, things seems not so easy.
The scene tab even does first appear after a autosart ruby has run, so no way to access the scenes via shortcut.

Other idea: Scenes can store the camera loctation. So can a ruby calculate a new camera location for each scene and write the property.
This would not update the screen or change the visible scene. But next time the scene-change is used it updates to the new location.
And the new camera locations are stored for each scenes in onSave.

What Propertys does ZoomExtents set? Is there a equivalent in ruby to calculate the values in the same way?

Regards

Hans-Peter

HPW

This does what I want:


 model = Sketchup.active_model
 pages = model.pages
 pages.each {|page|
    pages.selected_page = page
    UI.messagebox("Scene; "+page.name)
    view = model.active_view
    new_view = view.zoom_extents
    status = page.update(33) 
    }

But I have to press OK on the messagebox when scene-update has finished.

Edit: Kernel.sleep does not work for that.

Dan Rathbun

@hpw said:

Edit: Kernel.sleep does not work for that.

Yes.. I guess we decided it would not, because the C++ engine cannot call observers, as the scene changes, etc.