You have a line near the end of your code:
if Sketchup.active_model.rendering_options["EdgeColorMode"]
Since that will always return true (non-nil), then it always evaluates the first conditional. That's why it doesn't ever toggle.
You have a line near the end of your code:
if Sketchup.active_model.rendering_options["EdgeColorMode"]
Since that will always return true (non-nil), then it always evaluates the first conditional. That's why it doesn't ever toggle.
I don't know if there are specific advantages to either threads or begin-rescue-end. b-r-e should work fine, calling things in order then moving to the next, even if an error occurs. I suppose that the 'rescue' section could even lock down and block the trouble-causing item from being called the next time the observer is fired.
You would probably want b-r-e even with threading...
Is this regarding the PathCopy script from Smustard?
If so, I suspect that you have scaled the items you are trying to copy. If it's a component instance, PathCopy uses the definition and inserts new instances along the path. This would explain the change in scale. Also, the script uses the component axes for the initial placement along the path. So, you may need to redefine your component's axes, or inside the component rotate the geometry at the component's origin.
There are a few issues that I have on my list to update for PathCopy, but time is short...
I hadn't written it up yet (we were going to do a bit more content, then things happened) for the News feed. It should have appeared in the Scripts feed, though.
Another thought: while an AppObserver is model-independent (and is valid for the whole modeling session), all the others are model-dependent, and need to be recreated when a new model is started or a file is opened. Even though the observer instances are themselves still valid, the things they observe are gone, and thus nothing triggers them.
So, then, what are the ramifications of using a Singleton for model-specific observers?
An instance variable (or perhaps a class variable?) would contain an array of commands that are eval-ed in the observer definition. These commands could be added to the observer by other scritps, and the commands would call those scripts when the observer is fired.
require "singleton"
class AppObserver < Sketchup;;AppObserver
@@Commands = []
include Singleton
def onNewModel(*args)
@@Commands.each{|command| eval command}
end
def addCommand(*args)
@@Commands<<args if args.class==String
end
end
I know the 'eval' command gets a bad rap, but if someone is going to trust a script enough to download it, then 'eval' shouldn't be any worry, either, since the whole script gets 'eval'-ed anyway.
Obviously, the above example is pretty generic. There should probably be class/instance variables for each possible reactor in an observer, so that a script can reference the relevant actions individually. There should also be error-trapping (begin-rescue-end) and all that.
I've had some concerns about this. For Smustard scripts, I've started creating a few globals containing observer instances, and those globals can have observer actions added to them dynamically. This limits the number of observers to one of each type, and still allows multiple actions to be observed.
So far, so good. It would be nice if the SketchUp folks would handle this for us, but if we could all agree on a format, we could just get it done.
/Library/Application Support/Google Sketchup 6/SketchUp/Plugins/ is your location
Make sure that everything located here is a .rb file (there are a very few exceptions). If it's a .zip file, extract the contents to this folder (using any subfolder info saved in the .zip file).
Sometimes there are .so files that will be located here, but only .rb files will autoload when you start SU.
Also make sure you restart SU after adding any .rb files to this folder, or the plugins won't appear in your menus.
The last one was mine. The script doesn't exist (yet), and I've had the same idea for a script, just hadn't gotten around to making it reality.
There's a new script on Smustard called CADLayers. It is a two-part operation (for now) that uses a LISP routine in AutoCAD to export the names of layers that are frozen or turned off, and a Ruby script in SketchUp to read the list of layers and turn them off.
It should be useful for those whose workflow includes importing CAD files into SketchUp. I personally got tired of manually turning off the layers in SU that were already turned off in AutoCAD, and decided to automate the process.
The video was an illustration of how the tool would work, if it could be created. Currently, there is no ruby access to the internal dimension objects. In fact, if you create a dimension object, select it, then run the following code in the ruby console, you'll see that the object isn't even reported as a Dimension, but simply as a "DrawingElement". The second line of code will return the methods for the object - again, nothing even close to what would be required for the creation of this tool. The third line of code shows the methods for the Entities. There is no "add_dimension" method available, and there is no Dimension object like there is Edge, ArcCurve, Group, etc.
#the following line will get the class of the selected object
Sketchup.active_model.selection.first.class
#the following line will show the methods of the selected object
Sketchup.active_model.selection.first.methods.sort
#the following line will show the absence of an add_dimension method for Entities
Sketchup.active_model.active_entities.methods.sort
It could be put at the bottom of the list via ruby. Putting it at the top of the list would be a feature request best directed to the folks at Google.
I'm actually working on a SunStudy plugin right now. Trying to get the dialog working and looking the way I want it to.
There is a ChamferAlongPath script. I think Ashley could be persuaded to mod it for fillets...
PS - In an (obviously failed) attempt at avoiding confusion like has happened here, this note appears on the FP2 page:
@unknownuser said:
Note: Regardless of the accuracy of the settings made by this plugin, slideshows in SketchUp are always dependent on computing power, and may not display smoothly due to the overhead of calculating the views of the model in real time. The smoothest results will always come from exporting an animation.
How could I have explained it differently?
Not sure what you mean when you say you can't add a "normal" scene after using FP2. What is a "normal" scene? What happens when adding a scene that causes you to make this statement?
Just trying to understand...
There is an internal issue with webDialogs that cause them to lose their scrollbars. Usually, right-clicking in the window and selecting "refresh" or "reload" (or the appropriate similar menu item) will cause the scrollbars to reappear.
Unfortunately, there is no way for ruby to improve SketchUp's display performance (at least not that I have found). When exporting the animation to a video file, the transitions will be smooth and the page delay times will be appropriate to their settings. That is as good as it gets. Sorry
Might I suggest AddPages as a reference script? It adds pages (scenes) orthographically (based on user-supplied x, y, and z offsets). If I understand the gist of the discussion, then AddPages has at its heart the transformation code in question.
Ken,
I could look at doing a custom mod of ToDoList that would store all the info in the model. Thoughts?
If you have 100 or fewer actions to do your mods, you can undo them all.
You can also use "Save a copy as..." to avoid re-opening the master file.
The following code will automate the Undo actions:
100.times { Sketchup.send_action "editUndo;" }
Hope that helps,