Can't draw subclasses of Sketchup::Edge
-
That's a mighty interesting find! I'll try and play with that myself.
I'm still concerned about extending base class. It's so many ways there can be unforeseen trouble. I'd have to say it'd have to be last resort and the names needs to be very unique. (Remember that the API could add new methods in new releases.)
If SketchUp get around to use Ruby 2.0 there might be a better way around this as there appear to be a new feature in Ruby where one can make local modifications.
Btw, instead of
-1*entity.entityID
you can just useentity.entityID.abs
.... I have to say - I don't quite understand how your extend module works... I thought one passed a module to #extend() - and the module methods could be added to the instance you extended. But you have a class within your GcodeEdge module.... ?
-
@thomthom said:
That's a mighty interesting find! I'll try and play with that myself.
Thanks! Just remember: the real entity's base instance methods do not work even if you've retrieved the correct entity, only the mixin methods and data work. Calling something as simple as entityID on the real entity within onEraseEntity will throw an error, but if I've mixed in module functionality, all of the module's functions and variables work fine.
That's given me enough to work with that I have completely solved my cleanup problem.
@thomthom said:
I'm still concerned about extending base class. It's so many ways there can be unforeseen trouble. I'd have to say it'd have to be last resort and the names needs to be very unique. (Remember that the API could add new methods in new releases.)
... I have to say - I don't quite understand how your extend module works... I thought one passed a module to #extend() - and the module methods could be added to the instance you extended. But you have a class within your GcodeEdge module.... ?
I'm still fumbling around with module as it is, my priority right now is to get everything to work. I'm building a pretty robust unit testing suite as I go and I test every other line or so, so if I mess up the module and break something, I'll know it. The entire point of this is for personal use, I'm not focusing on release...but I don't mind future-proofing it either, if there's a way to get what I want done.
By now we've discussed it enough that I believe you have a pretty good idea of what I'm trying to do...if you have a suggestion for a different way I should implement this so it plays nicely, I'm open to suggestions.
-
Well, since you can't call the native methods on the erased entities you could make your identity hash refer to a data container with your data instead of the entity itself. And then avoid extending the Sketchup::Edge entities.
But if it's entirely for internal use then you're a lot safer as then you control the environment. Trouble starts when one release it for consumers.
-
Oh, hell, I'm an idiot. I understand what you mean now, and I'm not sure why it took me this long.
Okay, I've rebuilt almost all of my functionality into its own class (class GcodeEdge in module Grays42_Gcode_Paths) that stores a single reference to the associated edge as an instance variable. All of the actual toolpath building is done by a container class, GcodeRoute, that stores a stack of GcodeEdges and never actually touches the edge entities themselves. Everthing works so far.
That should resolve any potential conflicts. Sorry about that.
-
I hope we get to see your creation one day. It sounds interesting!
Advertisement