ChiefPlagman

On 12/17/2021 at 1:52 PM, Alaskan_Son said:

I'm curious if there are any other hidden formatting controls

No.

On 12/17/2021 at 1:52 PM, Alaskan_Son said:

this method works when a Measurement is converted to a float as well

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.

On 12/17/2021 at 1:32 PM, Alaskan_Son said:

I don't see that one listed anywhere in the documentation. 

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.

On 12/17/2021 at 2:30 PM, Chopsaw said:

for someone starting out it would be a lot easier if the items that need to be substituted were another color or italicized or something

I'll submit a request for this too

18 hours ago, Alaskan_Son said:

The shortcuts only work with a limited subset of the built-in units. I suspect in large part that is due to the formatting limitations imposed by Ruby’s method naming conventions.  It’s probably just too risky to allow custom units to create matching methods when there’s no telling what the name of that unit might be.  

This is correct. We don't place restrictions on unit names.

20 hours ago, Chopsaw said:

Is there a way to use the rest of the formatting "convert_to(unit: Symbol | String)"  to display the "units" ?

Or do you need to create a complete NumberFormatter for that with unit=("acre") in it ?

This method doesn't allow further control over the formatting, but you could try:

area.to_s("acre")

3 minutes ago, Chopsaw said:

Are you working towards providing other "ruby equivalents"

We do have tasks/requests logged to make global macros work with Ruby.

On 4/11/2021 at 7:10 AM, MoeGia said:

I'm wondering why the Chief supplied macros don't work with multiplication.

"Global" text macros, such as "room.area.internal", are not parsed by Ruby. They are simply replaced with text.

15 hours ago, Joe_Carrick said:

I think CA should provide that in their help files or a separate PDF for us.

See "Measurement and NumberFormatter Classes" under "Ruby in Chief Architect" in Help.

• 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.

1 hour ago, ACADuser said:

 

When I try to download the PDB files I can only get the first page, not the entire document.

 

Is there a trick to this? Not familiar with pdb files.

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 https://en.wikipedia.org/wiki/Program_database

17 minutes ago, BrownTiger said:

Every plane, every plane has this hidden value "object_id". It is never disclosed by ChiefArchitect, and appears to be immutable.

https://ruby-doc.org/core-2.4.0/Object.html#method-i-object_id

Just to be clear, object_id is provided by Ruby.

Roof planes.

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

=cabinet.room.name

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.

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.

You could enter

= backsplash_length * cabinet.backsplash_height / 144

after choosing "Apply Formula to Source Object" in the Count column.