Garage Door Labels - Default

[stevenyhof]

See video...

I'm trying to set up my default garage doors in my User Catalog but they always change to 9 X 7 GARAGE DOOR.

https://www.loom.com/share/3b39de6f1b7c4a41a5a3b922c63d069c

[stevenyhof]

Default Label Formatting
Custom labels can include a variety of macros that report size information about the object. This information can be reported in either of two ways:
• Default Formatting includes the unit of measurement after each macro reporting size information. In files using US Units, sizes are described using fractional inches with up to 1/16” accuracy.
• When Default Formatting is not used, units of measurement are not shown and decimal inches are used.
You can specify whether to Use Default Formatting in the object’s specification dialog. See Label Panel.

Anyone who knows Macros like to send me/us the macro to make labels automatic for garage doors?

 

[Alaskan_Son]

%(width.to_f/12).round% x %(height.to_f/12).round% GARAGE DOOR

[BBoumaConst]

I really hope someone has an "in feet" macro also, because reporting a garage door size in inches is annoying. For now, I just have 18 x 8 written in the label box, since that is usually the door size we use. At least that way, I don't have to change the label most of the time. 

 

Side note, we received one of your drawings to bid a couple of weeks ago from Mosaic! It's kind of neat to see how other CA users utilize the program. I only opened it to see if the drawings were similar to the original ones from Edgewater planned with the hotel, otherwise I rarely look at bid plans. I was an estimator at Lamar Construction and that was one of my projects. 

[stevenyhof]

5 minutes ago, Alaskan_Son said:

%(width/12).round% x %(height/12).round% GARAGE DOOR

 

Thank you Michael! 
Michael, I'm assuming you know a bit about the Marcos? I would love to toss some money in your direction to spend an hour learning about this.

[Doug_N]

7 minutes ago, Alaskan_Son said:

%(width/12).round% x %(height/12).round% GARAGE DOOR

 

%(width/12.inch).round% x %(height/12.inch).round % GARAGE DOOR  

 

Adding ".inch" to the divisor removes the inch (") symbol after the results.

[stevenyhof]

1 minute ago, Doug_N said:

%(width/12.inch).round% x %(height/12.inch).round % GARAGE DOOR  

 

Adding ".inch" to the divisor removes the inch (") symbol after the results.

Perfection!
%(width/12.inch).round% x %(height/12.inch).round% GARAGE DOOR

[Doug_N]

Michael is the guy, I am just a novice with Macros

 

[stevenyhof]

This is so amazing!! 
I did also find out that I can add the door I want into a drawing, size it to be the default I want, and save it (with the macro into the Label) into the library and it will save the macro.

 

[Doug_N]

Glad to help.

[Alaskan_Son]

45 minutes ago, Doug_N said:

%(width/12.inch).round% x %(height/12.inch).round % GARAGE DOOR  

 

Adding ".inch" to the divisor removes the inch (") symbol after the results.

Sorry, I just quickly tapped that out on my phone.  Not at the computer.  I wouldn’t recommend your solution as a general rule since the results technically store the information as inches (a very small garage door  ) and getting into that habit could result in some incorrect values when used in calculations.  There are other ways of storing an accurate value using .to_ft and there are tons of other approaches I could have taken, but using the original method I listed above, the safer syntax (and what I corrected my original post to say) is...

 

%(width.to_f/12).round% x %(height.to_f/12).round% GARAGE DOOR

[stevenyhof]

1 minute ago, Alaskan_Son said:

%(width.to_f/12).round% x %(height.to_f/12).round% GARAGE DOOR

Well, I will remember this if I run into an issue. I just went through and set up like 15 different typical garage doors and set their sizes and saved them into my library. It all works great for now. It did not take too long if I need to change it later. 

[Doug_N]

40 minutes ago, Alaskan_Son said:

Sorry, I just quickly tapped that out on my phone.  Not at the computer.  I wouldn’t recommend your solution as a general rule since the results technically store the information as inches (a very small garage door  ) and getting into that habit could result in some incorrect values when used in calculations.  There are other ways of storing an accurate value using .to_ft and there are tons of other approaches I could have taken, but using the original method I listed above, the safer syntax (and what I corrected my original post to say) is...

 

%(width.to_f/12).round% x %(height.to_f/12).round% GARAGE DOOR

Hi Michael, 

 

About it storing the value in inches, I don't think so.  The result of dividing by .inches, causes Ruby to cancel out the units altogether.  the %width% variable is stored as x.inches, which is why in the original formula the result comes out y"  x z"   When %(width/12.inch).round% x %(height/12.inch).round% is used, all references to units is lost and the result becomes unitless.  At least that is what I think is happening.

Doug

[Alaskan_Son]

34 minutes ago, Doug_N said:

Hi Michael, 

 

About it storing the value in inches, I don't think so.  The result of dividing by .inches, causes Ruby to cancel out the units altogether.  the %width% variable is stored as x.inches, which is why in the original formula the result comes out y"  x z"   When %(width/12.inch).round% x %(height/12.inch).round% is used, all references to units is lost and the result becomes unitless.  At least that is what I think is happening.

Doug

Still away from my computer, but try this %12.in+12.ft% and see what you get.  

[Doug_N]

48 minutes ago, Alaskan_Son said:

Still away from my computer, but try this %12.in+12.ft% and see what you get.  

OK so that didn't divide out the units.  Different units and different operand.  Ruby displays the results in inches having converted the feet to inches then displaying the result in inches. If we do this instead %(12.ft+12.in)/1.inch% the result is 156 with no units.  

And with this %((12.ft+12.in)/12.in)% you get a numerical value that is unitless but is the number of feet - 13

[stevenyhof]

I tested my garage doors with your first code .inch and it works great. When I change it to 9' or 18', or heights of 7' or 8', the label is correct.

[Doug_N]

Mysterious but wonderful when it works.  

[Alaskan_Son]

6 hours ago, Doug_N said:

OK so that didn't divide out the units.

Sorry Doug,  just got back to my actual computer and realized that I was being sloppy again and misread your code earlier. What you did was just fine.  My bad .  I should have waited till I was able to focus a little better.

 

 

 

9 hours ago, stevenyhof said:

 

Thank you Michael! 
Michael, I'm assuming you know a bit about the Marcos? I would love to toss some money in your direction to spend an hour learning about this.

I'd love to help you if I can find the time.  In the meantime, here's a quick little lesson on the house.

 

Chief stores the height and width for your door as a Measurement in inches in Imperial plans (millimeters in Metric plans). 

 

In my original, sloppy, uncorrected version  of %(width/12).round%, I was taking the width (in inches), dividing by 12, and rounding it to the nearest whole unit.  So, for a 16'-1"(193") wide door, The actual result would have been 193"/12 (16.08333") rounded to the nearest whole unit (16").  The result would have been displayed simply as 16 (no unit indicator) if a person were to uncheck Use Default Formatting in the Label panel, but it would still be stored as inches, which is exactly the bad practice I was telling Doug to avoid.

 

My corrected version of %(width/12).to_f.round% took the value (in inches), divided by 12, converted to a float (essentially a number that includes fractional values in decimal form), and then rounded that value to the nearest whole number.  Note that a float is NOT a Measurement but a completely unit-less number. So the result would be 193"/12 or 16.08333" converted to a float (16.08333),  rounded to the nearest whole number (16).

 

Doug's correction of %(width/12.inch).round% took the value (in inches), divided it by a specific number (also in inches) and the result was a unit-less Measurement value.  This is completely fine for this particular use case, but it should be noted that the result is being stored in a somewhat funky state because it's still a Measurement but has no unit.  This is particularly weird if you try to add it to another Linear Measurement with a specified unit in which case you would get an error.  In addition, you wouldn't be able to even assign a unit without first converting the result to a float.  All this is a non-issue with your particular use case, but it’s something to think about while you’re learning the syntax and developing your own personal methods.

 

I think a more logical, more correct, and more useful method might simply be %width.to_ft.round% which would simultaneously convert the inches to feet (no math necessary on our part) and convert that to a float.  Using this same logic approach, a person could easily convert their door sizes to meters without needing to know the conversion with something like like %width.to_m% 

 

Anyway, there's a lot more to the Measurement class but it's really quite useful and can make very quick and easy work of otherwise complex calculations.  Quick example:

 

a = 1.ft + 1.m +1.in ----> 52.370079 in

b = a.to_m ----> 1.3302

...very quick and easy conversions.

 

I could spend all day digging deeper, but those are a few of the very basic basics as they relate to this particular topic at hand.

 

 

[Doug_N]

Michael,

 

Thanks for the update and lesson.  Whenever I get a chance, and that is not often lately (busiest year I have ever had) i try to do some Ruby coding.  

 

Where did you get the resource material to learn the syntax and methods?    The CA help file is amazingly terse.

 

Doug

[stevenyhof]

Thank you Michael! I too am overly busy, but I will reach out to you sometime in the new year as I want to take advantage of the macros to further automate my processes.