Yes it IS bugged ... (click to view) ...
Could be. Yes it IS bugged.
It has always done this behavior. Think about it for a minute. Whilst attached to the cursor the user has not yet actually created a new
ComponentInstance, so it is before the insert still a
ComponentDefinition. The core rendering code likely is shared.
No doubt. At the console …
Sketchup::ComponentDefinition.instance_method(:material=).owner #=> Sketchup::Drawingelement
Unless it is for supporting some “Team” feature. It is not explicitly documented on the definition class page.
It would be nice if the implementation was “formalized” as to what it’s purpose is or may be later. (Ie, sometimes they did things because they planned on supporting something later, but have never gotten around to the “later” part.)
Exactly what I was thinking ! And it would be nice to have a switch so it could be on or off.
WAIT. I just tested, and it gets weirder. When you place the component the instance is white. But when you save the model file, all the instances INHERIT their definition’s material.
But why not until the model is saved ? (That is just weird behavior.)
This is not implemented correctly. Then after the save, the “cursor definitions” STOP displaying the definition material because the save distributed the definition’s material to all the instances, THEN cleared the definition’s material (ie, reset it to nil.)
Changing the definition’s material to something else, then placing new instances, works as before up until the file save. At that point ALL the instances are repainted with the defintion’s current material (even the previously “Red” ones.)
On the one hand, it’s a nifty “trick” to repaint all instances of a certain component, but not really faster manually than the right-click “Select All instances” then paint the selection. And for code it may not be any better than simply painting the instances collection with an
Issue Logged …