Adding dynamic attributes to select their values in LayOut labels

Developers Ruby API
1

Can someone provide a code example of adding dynamic attributes to select their values ​​in LayOut labels? I tried several options but it doesn’t work for me. Obviously I’m missing something. Also wondering if this would work the same with groups? I would be very grateful for an explanation.

2

Probably not. Ie, dynamic groups are handled “specially” by the Dynamic Components extension.

  • The top level (of the dynamic hierarchy) must be a component, so groups must be nested beneath a dynamic component. (This does not mean that the DC instance must be placed at the model’s top-level.)
  • Both component definitions and instances can have a "dynamic_attributes" dictionary.
    • The definition’s dictionary serves as the master “mold” for all instances. It has the attribute formulae, default values and some other “housekeeping” data.
    • An instance’s dictionary would have any attribute values that differ from the definition’s defaults (but possibly only if there are more than a single instance.)
  • A nested dynamic group will only have a "dynamic_attributes" dictionary attached to the group instance.
  • This means in coding that an instance should always be checked first for the existence of the dynamic dictionary and certain attributes, before checking the object’s definition’s dynamic dictionary. (In the case of a group instance, the latter check is frivolous.)

That said, I’m not sure how deep down the LayOut Label tool will “dig” for attributes. I suggest you manually create some custom attributes and test access in LayOut.

1 Like
3

Covered many times in the Dynamic Components forum category.

However, using Ruby introspection you can discover the built-in methods that the extension itself uses.

dc = $dc_observers.get_latest_class
#=> #<DynamicComponentsV1:0x0000020ab91cfdc ... >

dc.public_methods(false).sort
# I won't paste the output here for brevity sake, do this at the Console
# see the full list of methods that the class instance has defined.

dc.method(:set_attribute).arity
#=> -4 
# Ie, (negative denotes variable, 3 required and additional optional args.)

dc.method(:set_attribute).parameters
=> [
 [:req, :entity], [:req, :name], [:req, :value], [:opt, :formula],
 [:opt, :label], [:opt, :access], [:opt, :options], [:opt, :formlabel],
 [:opt, :units], [:opt, :error], [:opt, :formulaunits], [:opt, :name_prefix],
 [:opt, :can_delete_formlabel]
]

Playing around with changing DC attribute parameters and viewing using Aerilius’ Attribute Inspector, here is a preliminary list for argument values …

All of the default values for optional arguments are nil (which means the extension will not change nor create that attribute;) … except for:

  • name_prefix which is an empty string.
  • can_delete_formlabel which is likely Boolean

The list of valid access settings include:

  • "NONE" if consumers can’t see or edit this attribute
  • "VIEW" if consumers can see this attribute
  • "TEXTBOX" if consumer can enter a value for this attribute
  • "LIST" if consumers can select a value from a list

This options is a ampersand separated string of name/value pairs that looks like a
web query string. It comes into play if the access setting for an attributeis set to “LIST.”

  • EXAMPLE: "Small=10&Medium=15&Really+Large=25"

The valid display units are:

  • "DEFAULT" (user’s model units)
  • "STRING"
  • "INTEGER"
  • "FLOAT"
  • "DEGREES"
  • "PERCENT"
  • "DOLLARS"
  • "EUROS"
  • "YEN"
  • "BOOLEAN" (true or false)
  • "INCHES"
  • "FEET"
  • "YARDS"
  • "POUNDS" (weight)
  • "CENTIMETERS"
  • "MILLIMETERS"
  • "METERS"
  • "KILOGRAMS"

Some of the valid formulaunits are:

  • "DEFAULT"
  • "LENGTH"
  • "FLOAT"
  • "STRING"
  • "INCHES"
    … perhaps more.
2 Likes
4

If we assume that you don’t mind classifying the components as IFC, this should work:

#it is a extract of code, you should make your own module

#sets an Attribute Dict
def setSpecificAtributes(dicName,propertyName,val,attType)
  dicName.set_attribute propertyName, "value", val
  dicName.set_attribute propertyName, "is_hidden", false
  dicName.set_attribute propertyName, "attribute_type", attType
end
#change with your own values...
parameterName = "WahteveryouwantinLayOut"
ifcDesiredValue = "ValueToLayOut" #MUST BE a string, LayOut don't like Float

#here you should ensure first that your selection is not empty
ents = Sketchup.active_model.selection
validEntities = ents.grep(Sketchup::ComponentInstance)
validEntities.each  do |instance|
  if instance.definition.attribute_dictionary("IFC 2x3")
      ifcDict = instance.definition.attribute_dictionary("IFC 2x3")
  elsif instance.definition.attribute_dictionary("IFC 4")
      ifcDict = instance.definition.attribute_dictionary("IFC 4")
  else
    next
  end

  ifcDesiredPset = ifcDict.attribute_dictionary("Pset_LayOut", true)
  setSpecificAtributes(ifcDesiredPset,"#{parameterName}",ifcDesiredValue,"String")
end
1 Like
5

@DanRathbun , @rtches , thank you for your explanations.
I work with groups and it doesn’t seem to work for them. Or am I missing something. Thank you.

6

(a) I explained the difference as handled by the DC extension.

(b) Groups are just “special” component instances whose definition does not appear in the Components inspector and are made unique (a new definition created) if they are manually opened for edit and more than one instance exists.

(c) They work best as a subpart of a parent component.

So perhaps determine which has better benefits to your workflow.

1 Like