To clarify, PageExIm should save the shadow settings if the scene saves them, but it will NOT export/import any model info data, and location is model info data, not scene data (since v6, I think).
If you're having trouble with shadow settings, first make sure the scenes are set to remember that data. If you're still having problems, contact me.
@chris fullmer said:
Interesting. I had not found it in the API, rather in the blog post here:
What's New in SketchUp 7
Posted by Scott Lininger, SketchUp Team SketchUp 7 contains several improvements to the Ruby API. Here's a quick tour of the best changes. I...
(sketchupapi.blogspot.com)
and the only hint it gives is this:
Delete your scenes via the API
my_page.eraseSo I assumed it was a page thing. Then when I looked for it in the API, it was not in the "page" class section.
So I see it now, and I'll go give it a shot. Thanks Rick,
Chris
Yes, it does give that impression. I can see why it was confusing.
Read the API carefully - the .erase method is for the Pages class, not the Page class. That's why your code didn't work. Try this:
pages.each{|page| pages.erase(page)}
Or, in your style
pages.each do |e|
pages.erase(e)
end
@martinrinehart said:
All scenes are used, unless you implement Animation.nextFrame to stop someplace.
Users can turn off whether a scene is used in a slideshow. I think that is what he was asking, but I could be mistaken...If I'm not, then:
For checking a page for use in animation:
if page.name==page.label #used in animation
It's kinda hacky, but it works. The reason it works is that SU puts parentheses around a name for the tab label. If the label (with parens) doesn't match the name (without parens), it's not used. If they match, it IS used. 
I previously requested a page.in_slideshow? method, but no dice yet (probably because of the available workaround), though it would be easy to code:
class Page
def in_slideshow?
return self.name==self.label
end
end
Then make it an externally loaded file contingent upon not having a native method:
require 'page-in-slideshow.rb' unless page.methods.include?('in_slideshow?')
or something like that, to handle a future native API method.
For checking available SU methods:
model.methods.sort-Object.methods
page.methods.sort-Object.methods
#etc
@fizgig said:
It would be nice if I could save the position somehow, go to the global context as shown in the code but then go back to the context when I'm done. That way the user doesn't have to re-double-click back to where they were.
I'm not seeing anything in the model class that would appear to do that. Anyone have any ideas?
It was requested, but hasn't made an appearance yet. I reaffirmed the request.
The "eyedropper" sounds similar to ApplyTo - or did I misunderstand something?
@jclements said:
Yeah, my feeling about "Weld.rb" ... it has been around for long time now and it must be a fluke since its not in the core program.
@gaieus said:
Hehe...Anyway, Weld was the only exception I asked the IT guys to install when they install SU on the computers. Yes, it IS part of the program (you just install it separately)
Okay, that clinches it. As soon as I am done with Repaint2, I'll need to carve out some time to work on Weld2...
For my part, I created the SmustardAppObserver that allows plugins to add calls to the Observer instance. When an event is triggered, the observer will parse the list of calls.
The SDK exposes SU to C++, but from what I hear, it's a bit of a mess.
One thing I've learned is to include a callback at the end of my html telling the script that the WebDialog is ready to receive communication, as you mentioned, and as I have mentioned in other threads.
@xrok1 said:
until SU developers put every function that the scripters have added, into the core program, they will get NO respect from me.
So the folks at @Last (who are the same people still developing SU after the buyout) don't get any respect for implementing Ruby in SU, thus making all those wonderful plugins possible?
Second, @Last's stance (carried on by Google) is to focus on the core product development and generally leave the plugins to third party developers. Besides, why should they bloat the core product with "every function that the scripters have added"? There are very few plugins with near-universal utility, and "every function" is a LOT of stuff...
Oh, I did notice the wink, but wasn't sure how you meant it...
I've used my SelectionMemory script to do the opposite - select edges outside the space I was in. Specifically, I would group a profile shape, select and "memorize" the edges to be used for FollowMe, then go inside the profile's group and "recall" the edges, then start the FollowMe tool and click on the profile face. It prevents the extruded shape from reacting to the edges of the path - very handy in some cases.
Organizer 1.4 is now available.
To update to Organizer 1.4, you have three possible options:
@avariant said:
And maybe related to that, as posted above, when you actually have a component open, the results are different than when you don't. I suppose there's no magic bullet until I can figure out what's different for the images that don't work...
The "magic bullet" (or as close as it currently gets) is to query the Sketchup.active_model.active_path which will return an array or nil. If it's not nil, then you're in a g/c and you'll see an array listing the hierarchy of objects and you can check all the transformations as needed.
@putnik said:
When an 'organised' script gets updated by its author, you have to go through all the steps again, which is a pain.
I suggest you lobby the other authors to make their works Organizer-compatible. That would cut down on the headaches for users.
@putnik said:
All in all a better script manager is really needed.
Unfortunately, a script manager relies on standards. If authors are unwilling to follow - or don't know about - the standards that allow the manager to function, things won't get any better.
@chris fullmer said:
The main problem is with the scripts that are encrypted so you can't edit them yourself. And I think Rick's script that Remus linked to is also limited by that same issue as well?
Only to the extent that if the original author didn't make it Organizer-compatible, it won't show up in submenus. Organizer can still load an "organized" .rbs file, but it will show up in the hard-coded menu, and OrganizerEdit (obviously) can't edit it to make it compatible.
I am updating Organizer again. The main change is for accommodating plugins that have subfolders for required files.
The update provides a mechanism for developers to easily exclude their subfolders so Organizer will not try to load the contents of those folders. This should result in a smoother experience for users, who won't have to contend with manually maintaining the excluded folders list in the SmustardOrganizerExcludeFolders.txt file.
Developers: in your subfolder, create a text file called "exclude.txt" that has as its contents the plain text name of the subfolder - that's it! You can use the attached file and change "myFolderName" to your subfolder's name if you want.
The new version should be available starting Monday (14 Sept 2009).
@jim said:
I was working on cleaning up and consolidating my own plugin mess earlier today, as a matter of fact. I hope to get all mine into a single sub-menu, along with some help and configuration items for each of them.
The challenge then becomes trying to remember who wrote that cool plugin that will do what you need.
I think we developers need to get on the same page, whatever that ends up being.
I'm glad you've found it helpful!
Yes, Repaint is overdue for some updates - I'll add them to my list.
What I've done in the past is to put a callback at the end of my HTML code to let Ruby know the dialog is ready to go.
...
</body>
<script type="text/javascript">
window.location="skp;done_loading@"
</script>
</html>