Macro ir Ruby

[Bill_Nelson]

Is there a macro, or a way to create a macro, to call out window dimensions in plan view from inches only to 0'-0" without having to edit the window label?

[Alaskan_Son]

Just sent you a PM.

[robdyck]

Interesting comparison  to an elevation point using the supplied macro (%elevationf%) which displays in feet -inches instead of inches like most other values.

When do we get the Number Style option to provide control per layer much like text style? This is a ridiculous lack of control and is a most basic function that should be available out-of-the-box. No offense to my pal Michael, but we shouldn't need to pay extra to a 3rd party to control the display of numbers.

[BrownTiger]

Example code:

 

WindowLabel.txt

 

I am not an architect.

And this is my hobby.

[robdyck]

1 hour ago, BrownTiger said:

Example code:

 

WindowLabel.txt

 

I am not an architect.

And this is my hobby.

I gave this a try, but it didn't work.

[Bill_Nelson]

I tried the windowlabel.txt with my C.A. X11 and had no success. Thanks to all who gave in put on this problem. And I agree RobDyck, something like this should come out-of-box friendly user available. coming over from Autocad to Chief, I always used foot-inch in my window callouts, that is how I was taught years ago. And unfortunately, the last few plans I have drawn using C.A X11 and using the window schedule label (symbol) showing the label and not the actual window dimension,the city planners have kicked back my drawings wanting to see the window callouts and not a label(symbol). Maybe it's LAZINESS on their end.

 

Thank you Alaskan_Son for offering your service. For now I will continue researching the ruby program and see if can figure it out, if ruby is what Is used to create a program. 

[Chopsaw]

11 hours ago, Bill_Nelson said:

I tried the windowlabel.txt with my C.A. X11 and had no success.

 

That one is definitely meant to be used with X12 but there is some sort of a glitch and is not quite functioning properly there either.  It needs to be set to Evaluate and Context: None

 

I will see if I can come up with one that works in X11 for you this weekend.

[misterwiley]

@Bill_Nelson I'd definitely recommend getting in contact with @Alaskan_Son. He supplied me with a couple different macros a while back that made this process a breeze. He's worth his weight in gold for all the help he provides us non programmer types.

[BrownTiger]

3 hours ago, robdyck said:

I gave this a try, but it didn't work.

 

You sure, you selected the window?

 

WindowTest.plan (X12)

[BrownTiger]

WindowTestX11.plan

[jscussel]

Works well in x12. However, it doesn't show fractions. 

[robdyck]

1 hour ago, BrownTiger said:

 

You sure, you selected the window?

 

WindowTest.plan (X12)

My bad, BrownTiger...I entered the text wrong, because anything macro related just ain't my bag, baby!

 

[Chopsaw]

2 hours ago, jscussel said:

Works well in x12. However, it doesn't show fractions. 

 

Here is a modified version Jon.  Still a little glitch that does not display properly in the Label column of a Window Schedule that I could not figure out and also had to comment out a couple of lines that were blocking the proper function of the fraction display, so it could fail for a different reason.

 

Possibly BT could explain or comment ?

 

BT Widow Label fr.json

[Bill_Nelson]

Thank you Solver for the video and the  *.jsn file. I did import the X11 label window file. I attached three files. One to show what happened when I used a window schedule, one without the window schedule. I did remove the default window label from the "window Specification". 

 

Is there a way to have the window callout shown in the "right window calllout JPG", (the far right window)?

 

Again, Thank you for all your help.

[Kbird1]

11 hours ago, BrownTiger said:

Example code:

 

WindowLabel.txt

 

I am not an architect.

And this is my hobby.

 

Thanks BT , appreciate it.....seems to work nicely....

 

5 hours ago, jscussel said:

Works well in x12. However, it doesn't show fractions. 

 

 

It will if you change the .round(0) to .round(2) in the Macro,

 

BT has set it up to use Fractions (1/8ths) ( 2nd pic), it could be 16th or 32nd or 64th etc. ( change it as needed)

He just didn't set it to use them in this particular case, since round(0) rounds to the nearest whole Inch (integer) up or down per normal.....

 

  

 

 

* Note  I have also made a few other minor alterations to the Code , so yours may not look the same....

 

Mick.

 

[BrownTiger]

Lol. Thank you Kbird1. I had no idea that someone really orders windows to 1/16th. Last time I ordered instead of 3072 I got 9072. Beautiful window three times the width after 4 month of waiting. 

 

You do not have to use the label, and it does show up in the scheduler. Here I added another macro windowGoldenRatio and custom OIF, that informs a designer that the window [or  may be a building] has an incorrect factor. 

 

WindowTest.plan

 

#Macro: windowGoldenRatio

result = ""

referenced ? obj = referenced : obj = owner

result ="Golden ratio [1:1.618]: This Window =[1:" + (obj.height / obj.width).round(2).to_s + "]\n"

result

 

[BrownTiger]

If your window scheduler did not get updated just delete it and regenerate.

 

[Kbird1]

3 hours ago, BrownTiger said:

Lol. Thank you Kbird1. I had no idea that someone really orders windows to 1/16th.

 

Not 1/16th no , at least not me , but on Retro Fit Jobs ordering custom sizes to fit old Openings I regularly Ordered to 1/4" , but your 1/8th Handles that too.

 

Rounding to the nearest inch isn't really a good thing as for eg. 41 1/2" will become 42" etc.

 

Thanks for the new Code too... 

 

M.

[Alaskan_Son]

22 hours ago, Chopsaw said:

That one is definitely meant to be used with X12 but there is some sort of a glitch and is not quite functioning properly there either.  It needs to be set to Evaluate and Context: None

 

You were right the first time.  It didn't work because there was an error in one of the lines that BT fixed in the follow-up sample plan...

 

dim = $FtIn.apply(obj.width.round(0)) + "w x " + $FtIn.apply(obj.height.round(0).to_s) + "h" #You can't apply the X12 NumberFormatter to a string

[Alaskan_Son]

21 hours ago, solver said:

This works in X11, untested in X12 or newer.

Typically the only thing you have to do to ensure your code will work in both X12 and in older versions is explicitly convert your desired object attributes to floats.  So, your macro would just need the last line to read...

 

ConvertToFeetInches(height.to_f,16, "-", "-", true) + "x" + ConvertToFeetInches(width.to_f,16, "-", "-", true)

[Chopsaw]

49 minutes ago, Alaskan_Son said:

23 hours ago, Chopsaw said:

That one is definitely meant to be used with X12 but there is some sort of a glitch and is not quite functioning properly there either.  It needs to be set to Evaluate and Context: None

 

You were right the first time.  It didn't work because there was an error in one of the lines that BT fixed in the follow-up sample plan...

 

dim = $FtIn.apply(obj.width.round(0)) + "w x " + $FtIn.apply(obj.height.round(0).to_s) + "h" #You can't apply the X12 NumberFormatter to a string

 

Thanks Michael,  I went through the text file and the plan file with a line by line comparison and somehow missed that and was confused as I was not even getting the same error as Rob posted.

 

Any thoughts on what is going on with the schedule display of the label.  I am seeing the same issue in BT's x12 macro as Bill posted in the revision cloud using Eric's x11 version.   Chief bug or ruby complication perhaps ?

 

Many Thanks,   Chopsaw

[Alaskan_Son]

2 hours ago, Chopsaw said:

Any thoughts on what is going on with the schedule display of the label.  I am seeing the same issue in BT's x12 macro as Bill posted in the revision cloud using Eric's x11 version.

 

I don't think the example was using Eric's code at all.  And I didn't disect BT's code that far.  It looks at least a tad over-complicated though and a bit too dependent on the automatic label.  When setting up custom labels like this, I find its typically best to build them from scratch for the desired use, using only the source values (schedule_number, width, height, and type_code in this case), and keeping them as simple and as explicit as possible.  In this case, the desired label formatting could pretty easily be accomplished in as little as a single line of code and without all the unnecessary error handling...although I would likely use about 3 lines of code.   

 

EDIT:  I took a quick look at BT's code and it looks like the problem is almost certainly the result of the conversion of a text string to an integer.  .to_i converts only leading numerical values to an integer.  If there are no leading numerical values, than the result is zero. 

[BrownTiger]

I am sorry, I type and fix staff faster than I think, so must have fixed it even without noticing.

It took whole 3 minutes to create these demo plans.

 

>ConvertToFeetInches(height.to_f,16, "-", "-", true) ....

 

1. I assumed you locally defined this ConvertToFeetInches function right?

2. Generally I do not like this object  cast .to_f, reminds me of the old days of ADA.

3. It would have made more sense for CA to implement .to_ftin... Instead of us embedding local converter functions. Just my $.02

4. .to_in ... makes no sense to me because it gives you the decimals. I fully dig .to_mm or .to_m because they are decimals, but what in the heck is 7.23" really is, why would someone want decimal representation of an empirical unit? ( Same, If someone in the past game me a plan where a part  was dimensioned: 10 3/16 mm I would have told him where exactly to put that design).

5. Where our instrument nonius is 10 (e.g. 0.01 mm) no point. The reason I am saying this I have learned not to convert and use decimals with metric and fractions with imperials. Even if software uses for some reason that internally it should never be a default display.

[Chopsaw]

2 hours ago, Alaskan_Son said:

EDIT:  I took a quick look at BT's code and it looks like the problem is almost certainly the result of the conversion of a text string to an integer.  .to_i converts only leading numerical values to an integer.  If there are no leading numerical values, than the result is zero. 

 

Thank You.

[Chopsaw]

22 minutes ago, BrownTiger said:

3. It would have made more sense for CA to implement .to_ftin... Instead of us embedding local converter functions.

 

Yes I believe it was requested and should definitely not been something that needed to be requested after the fact.

 

22 minutes ago, BrownTiger said:

4. .to_in ... makes no sense to me because it gives you the decimals. I fully dig .to_mm or .to_m because they are decimals, but what in the heck is 7.23" really is, why would someone want decimal representation of an empirical unit?

 

It is used in other disciplines but not so much in residential construction.