Ruby macro evaluation error, x9 final release

[AgChief 0]

Anyone else getting #EvaluationError# on macros since the x9 final release?  Things were working fine until the update to the final, non-beta, x9 version.  I have a set of working drawings to finish up.....

 

Here's the offending macro, it's purpose is to show the header height on a window label:

 

arr = top_elevation.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

 

evalerror.plan

[Joe_Carrick 2325]

John,

 

Try this:

arr = owner.header_elevation.round().divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round()}\" H.H."

[Alaskan_Son 2474]

The top_elevation attribute seems to be the problem.  The value is being reported as blank.  This needs to be fixed pronto.  Please send in a bug report. 

[AgChief 0]

Thanks, Joe.  It looks like Chief has added formatting to %top_elevation%.  I can avoid the error by changing the original macro by substituting header_elevation for top_elevation in the macro.  Adding "owner." to the macro doesn't seem to have an effect.

 

The following macro does give a valid result but "header_elevation" isn't what I'm looking for, as it accounts for the 1/2" at the top of the window for the rough opening then rounds up to the next whole number.  In this case it would result in 6'-11" instead of 6'-10"

 

arr = header_elevation.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

Like I mentioned, I think Chief must've added the quotes to the formatting to denote inches, which screws up my macro.  See the attached image to see the difference in the results.

[Alaskan_Son 2474]

12 minutes ago, AgChief said:

Thanks, Joe.  It looks like Chief has added formatting to %top_elevation%.  I can avoid the error by changing the original macro by substituting header_elevation for top_elevation in the macro.  Adding "owner." to the macro doesn't seem to have an effect.

 

The following macro does give a valid result but "header_elevation" isn't what I'm looking for, as it accounts for the 1/2" at the top of the window for the rough opening then rounds up to the next whole number.  In this case it would result in 6'-11" instead of 6'-10"

 

arr = header_elevation.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

Like I mentioned, I think Chief must've added the quotes to the formatting to denote inches, which screws up my macro.  See the attached image to see the difference in the results.

 

Looks like hat top_elevation attribute is more broke than I thought.  It works when placed directly into the label but otherwise the value is being reported as blank...

Please report those issues to tech support.

[Alaskan_Son 2474]

By the way, you can pretty easily get what you're after with something like this...

 

arr = (header_elevation-rough_opening_top).round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

...but I question whether you are fully understanding the relationship between the window size and the the rough openings.

[AgChief 0]

I think the issue is that since top_elevation has the string formatting, the macro blows a fuse when it tries to evaluate a string in a real equation.

[Alaskan_Son 2474]

16 minutes ago, AgChief said:

I think the issue is that since top_elevation has the string formatting, the macro blows a fuse when it tries to evaluate a string in a real equation.

 

No.  It's not that simple.  If that were the case you would be able to fix your problem macro with something like this...

 

arr = top_elevation.to_s.sub('"', '').to_f.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

OR

 

arr = top_elevation.to_s.gsub("\"', "").to_f.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

 

or similar.

 

If you look at my attached screenshot you'll see that the top_elevation has NO VALUE in text macro management.  Try creating a test macro using nothing but top_elevation and you'll see what I mean.  It's not working right at all. 

[AgChief 0]

Exactly.  It's not working after the x9 update, when it was working perfectly fine before.  Before the last update %top_elevation% returned the top of the window in inches, which I then formatted to feet and inches in a format (ie., 6'-10" H.H.) that my working drawings have had for years.  I never consider rough opening when I call out the header height so why would I go to the trouble of doing the math in an equation when that information is (or, has been and should be) provided by %top_elevation%?

[Joe_Carrick 2325]

John,

 

The owner simply eliminates the need to specify owner context.

header elevation accounts for the rough_opening_top so if you change the macro to:

 

arr = (header_elevation-rough_opening_top).round().divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round()}\" H.H."

 

you will get the same result you did before.

 

The problem currently is that the top_elevation is nil.  It's neither a numerical value or a string.

• top_elevation.round() is the same as nil.round() which generates the error.

CA needs to properly initiate the top_elevation & bottom_elevation attributes.

 

[Joe_Carrick 2325]

ps:  Another way to see this is to open the Ruby Console and type:

• owner.top_elevation <enter>
• the result is nil

    or

• owner.top_elevation.nil? <enter>
• the result is true

[Alaskan_Son 2474]

32 minutes ago, AgChief said:

Exactly.  It's not working after the x9 update, when it was working perfectly fine before.  Before the last update %top_elevation% returned the top of the window in inches, which I then formatted to feet and inches in a format (ie., 6'-10" H.H.) that my working drawings have had for years.  I never consider rough opening when I call out the header height so why would I go to the trouble of doing the math in an equation when that information is (or, has been and should be) provided by %top_elevation%?

 

I hate to break it to you but I think you have been modelling/displaying those dimensions inaccurately for years.  I think you are misunderstanding the window settings.  Study the attached screenshot and I think you'll see what I'm talking about...

 

 

[Joe_Carrick 2325]

I agree with Michael.  Of course he has exaggerated the Top and Bottom Rough Opening values - but it does illustrate the point. 

[AgChief 0]

Nope.  I'm not referring to "modelling" as I've been drafting on 2D Autocad for my entire professional career.  I'm simply referring to placing a note on the plans telling the framer where to set the top of the window.  When I've framed window openings and on every set of working drawings I've ever done where the top of the window is referenced, it is referred to as "Header Height", and as far as I've experienced it's been common nomenclature in this profession.  I've been doing this for over 25 years and have never, ever had an issue with a framer in terms of window placement height so believe me, all of these years I've obviously been doing something right.

 

This thread was intended to point out a potential bug and to see if anyone else had experienced it.  I'm certainly not an expert in Ruby, but I've had success with this macro in the past, and when it doesn't work after an update it logically follows that there's a bug.

[Joe_Carrick 2325]

12 minutes ago, AgChief said:

This thread was intended to point out a potential bug and to see if anyone else had experienced it.  I'm certainly not an expert in Ruby, but I've had success with this macro in the past, and when it doesn't work after an update it logically follows that there's a bug.

 

Yes, and I've reported it to CA. 

 

I also had a macro for Vent Labels that used bottom_elevation that didn't work in X9.  I've modified it to use other attributes but IMO CA should not make changes that cause things that worked to quit working.

[AgChief 0]

Thanks, Joe!  I've reported it too so maybe we'll get a quick fix.

[Alaskan_Son 2474]

1 hour ago, AgChief said:

Nope.  I'm not referring to "modelling" as I've been drafting on 2D Autocad for my entire professional career.  I'm simply referring to placing a note on the plans telling the framer where to set the top of the window.  When I've framed window openings and on every set of working drawings I've ever done where the top of the window is referenced, it is referred to as "Header Height", and as far as I've experienced it's been common nomenclature in this profession.  I've been doing this for over 25 years and have never, ever had an issue with a framer in terms of window placement height so believe me, all of these years I've obviously been doing something right.

 

This thread was intended to point out a potential bug and to see if anyone else had experienced it.  I'm certainly not an expert in Ruby, but I've had success with this macro in the past, and when it doesn't work after an update it logically follows that there's a bug.

 

Sorry, I wasn't trying to suggest you have been drawing up plans incorrectly just that you have been drawing your 3D models incorrectly and using the wrong attribute all along.  Yes, it worked for you but technically you should have been setting your window height lower and using the header_elevation all along.  If you changed your practice your problem would be solved. 

 

Having said that, the attribute is definitely broken and needs to be fixed no matter what.  Thank you for reporting it. 

[OkcDesigner 20]

CA this is same issue noted in another topic I started this morning......."Why I hesitate to customize CA using Macros"

 

it appears this macro lost ability for "window top_elevation" and caused my working macro to stop working as well. "top_elevation"

[Joe_Carrick 2325]

I received a notice from Brian at CA that he could reproduce the error and logged the issue.

[AgChief 0]

Joe, I dropped your name when I contacted tech support, so that's probably what sped things up!  

[AgChief 0]

On 2/15/2017 at 2:54 PM, Alaskan_Son said:

 

Looks like hat top_elevation attribute is more broke than I thought.  It works when placed directly into the label but otherwise the value is being reported as blank...

Please report those issues to tech support.

 

Reviewing this thread, I just noticed that my "ObjectProperties" is different, and I have absolutely no idea why.  Is your "ObjectProperties" the stock version or did you change it?  See the attached pic.

[Joe_Carrick 2325]

Here's my version of Object Properties.  It works much better IMO.

_Object Properties.json

[Alaskan_Son 2474]

36 minutes ago, AgChief said:

 

Reviewing this thread, I just noticed that my "ObjectProperties" is different, and I have absolutely no idea why.  Is your "ObjectProperties" the stock version or did you change it?  See the attached pic.

 

That screenshot I posted was from YOUR plan.  All I did was quickly change referenced to owner to get what I wanted.  But yes,  I have personally changed that macro in my template plan.  Not sure why Chief doesn't modify the OOB macro for that.  The one Joe just provided looks a little different then mine but it appears to have the exact same results.  

 

In essence all you really need to do is change the top line to read referenced ? obj = referenced : obj = owner

[AgChief 0]

18 minutes ago, Joe_Carrick said:

Here's my version of Object Properties.  It works much better IMO.

_Object Properties.json

 

Thanks, Joe!