'Area' Units in Dynamic Components?

[ed.p.may]

Hello all,

I’m working on a small ruby plugin and wondering about how to properly set dimension units in my Dynamic Components? I have read elsewhere in this forum about how to set the length units (very helpful) but I’m wondering if there is a similar set of steps to use for area units? ft2, m2, etc…

I experimented with a couple options but couldn’t get anything to work. Is anyone aware of how to set these type of units correctly?

thanks very much for any info,
-Ed

[eneroth3]

There is no proper way to interact with Dynamic Components from another extension. Dynamic Components doesn’t have a public API and all interactions with it is basically just hacks that risk stops functioning if it is ever updated.

I’d recommend to implement the behaviors you need in your own code base directly.

[ed.p.may]

Ah - thank you very much. Thats helpful to know.

I’d seen similar suggestions re: DC’s on other posts (ie: “Don’t use them”) but for the tool I’m working on I need (want) to pass data from the Sketchup components over to the Layout environment for use in ‘AutoText’ labels and tags. It seems to me, just from reading the Skp help pages, that only DC’s are able to pass data from their attribute dictionaries between the applications? Does this seem correct as far as you know, or do you think there is a cleaner method (not using DCs) that I’m missing which would be the better process for passing data to the Layout side?

Other than the ‘units’ issue I’ve been able to get it all to work as desired so far, though the point about unforeseen changes to the DC code is well taken.

thanks so much,
-Ed

[eneroth3]

I’ve haven’t used LO’s autotext much but I think it can read component names, descriptions, instance names and likely the attributes added in 2018 (prize etc). I’m not sure if LO gives DC any special treatment by reading that extension’s attributes. I hope it stays neutral and don’t have hardcoded functionality for only a single extension.

DC is fine to use as a user, but developers should stay away from building upon it, in the same way an architect can’t skip a wall and instead use the neighboring building as support. There’s a difference between experimenting and creating something that happens to work (right there and then) and build it according to good practice and make sure it stands stable in the future.

[MikeWayzovski]

You can use any attribute that is set to visible in LayOut’s label tool.

[ed.p.may]

Thanks @MikeWayzovski,

Thats interesting, I am not able to get that to work for some reason though? If I make a quick component and try and add some data to a new attribute dictionary (that is: not the ‘dynamic_attributes’ dictionary) using something like:

sel = Sketchup.active_model.selection

sel.each do |s|
	if s.class == Sketchup::ComponentInstance
		s.definition.set_attribute('my_attributes', '_mytest_access', 'VIEW')
		s.definition.set_attribute('my_attributes', '_mytest_label', 'myTest')
		s.definition.set_attribute('my_attributes', '_mytest_formlabel', 'Some test label') 
		s.definition.set_attribute('my_attributes', '_mytest_units', 'FLOAT')
		s.definition.set_attribute('my_attributes', '_mytest_formatversion', 1.0)
		s.definition.set_attribute('my_attributes', '_mytest_hasbehaviors', 1.0)
		s.definition.set_attribute('my_attributes', 'mytest', "Some test value")
	end
end

I can’t seem to get that new value to pass over Layout? The new attribute value and dictionary seem to get added to the component definition just fine:

but for some reason I just don’t see that new attribute dictionary available in my Auto-Text tags in Layout:

If use basically identical code, but add the new data to the ‘dynamic_attributes’ dictionary instead, it seems to work and I have access to my new attribute value in Layout as expected:

sel = Sketchup.active_model.selection

sel.each do |s|
	if s.class == Sketchup::ComponentInstance
		s.definition.set_attribute('dynamic_attributes', '_mytest_access', 'VIEW')
		s.definition.set_attribute('dynamic_attributes', '_mytest_label', 'myTest')
		s.definition.set_attribute('dynamic_attributes', '_mytest_formlabel', 'Some test label')
		s.definition.set_attribute('dynamic_attributes', '_mytest_units', 'FLOAT')
		s.definition.set_attribute('dynamic_attributes', '_mytest_formatversion', 1.0)
		s.definition.set_attribute('dynamic_attributes', '_mytest_hasbehaviors', 1.0)
		s.definition.set_attribute('dynamic_attributes', 'mytest', "Some test value")
	end
end

Can you spot where I’m going wrong there? It does seem to make sense as @eneroth3 says to try and use deliberate dictionaries if they are actually able to pass their data over, rather than building on top of the dynamic_attributes.

much thanks!
-Ed

[eneroth3]

It seems the LO team has made an exception for Dynamic Component and hard coded functionality for it into the application, rather than implement a general solution that everyone could use .

DC is a weed with very deep roots.

[MikeWayzovski]

Yes I was talking about the Dynamic Component Attributes, not self-created libraries, srry if misunderstood. I always get torn between existing functiona-lity, and how it should suppose to work-lity

maybe the DC’s will get the attention they need, someday…

[ed.p.may]

Ah, gotcha, Ok thank you both. So long as I’m not missing an easy, obvious solution I’ll keep working with the DC attribute dict.

thanks!
-Ed