Chief Architect
  • Posts

  • Joined

Everything posted by ChiefPlagman

  1. No. to_f is the same as convert_to, but the unit argument is optional. If it isn't provided we use the default unit specified in the documentation for that category of Measurement. I submitted a request for to_s to be added to the documentation. I'll add to_f too. Since we allow an extra argument compared to most built-in Ruby classes it seems important. To the best of my knowledge most Measurement methods that accept a variable amount of arguments will produce an error message that includes the expected number of arguments, as well as what they should be, if too many are provided. The exceptions should be cases where we delegate to the behavior of the Ruby Float class. I'll submit a request for this too
  2. This is correct. We don't place restrictions on unit names. This method doesn't allow further control over the formatting, but you could try: area.to_s("acre")
  3. We do have tasks/requests logged to make global macros work with Ruby.
  4. "Global" text macros, such as "room.area.internal", are not parsed by Ruby. They are simply replaced with text.
  5. See "Measurement and NumberFormatter Classes" under "Ruby in Chief Architect" in Help.
  6. Macros from versions before X12 that have not been migrated should continue working in X12. You do not need to do anything if you merely want to use your existing macros or new macros that don't interact with your existing macros. However, referencing a legacy macro that has not been migrated from a new macro written in X12 (or vice versa) might cause an error. During the migration process you will be able to compare the results of the macro before and after migrating and have the opportunity to make changes if needed. Not all macros will require any changes while migrating. For more information, see "Considerations for Legacy Files" and "Migrating Legacy Ruby Code" in Help.
  7. If you're referring to the Plucker docs linked in the Downloads page on that site, I'm not familiar with that format or those downloads. PDB more typically refers to
  8. Just to be clear, object_id is provided by Ruby.
  9. You can obtain the full text shown in the Size column with "=formatted_size", but that text is computed from the dimensions when the material list is generated. We don't currently expose the individual dimensions themselves. For the room, you could use
  10. The list of units is limited whenever the Count column formula hasn't been edited. I don't think we currently have name-value pairs for drawer/door dimensions.
  11. The "Insert Macro" button in the cell editor offers a subset of available items when "Apply Formula to Source Object" is selected, including backsplash_length under the menu "Object Specific". For the backsplash row, there is a second menu called "Parent Object", which in this case refers to the cabinet itself. Items in that menu are prefixed with "cabinet." when they are entered into the cell (you may notice "cabinet" is also listed under the "Object Specific" menu. That means any property of the cabinet is available in that cell as long as it is prefixed with "cabinet."). Ideally, backsplash_height would show up there, but we're currently displaying a limited set of properties in that menu for usability reasons. If we listed everything, certain objects would cause the menu to grow very large. We're working on improving that UI. At the moment, there are two ways to see the complete list of properties (a.k.a "name-value pairs") for an object. 1. When you have an object selected in a view, open the Ruby Console and enter "owner.names.sort". 2. Use a User-Defined Text Macro, such as %object_properties%. Anything listed there for a cabinet is available in the material list. As a side note, name-value pairs that return numbers are either unitless, inches/millimeters, square feet/square meters, or cubic feet/cubic meters.
  12. You could enter = backsplash_length * cabinet.backsplash_height / 144 after choosing "Apply Formula to Source Object" in the Count column.