Ruby macro evaluation error, x9 final release


AgChief
 Share

Recommended Posts

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

x2scrap.png

Link to comment
Share on other sites

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.

x2scrap3.png

Link to comment
Share on other sites

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.

x2scrap3.png

 

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

Top.png

Please report those issues to tech support.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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%?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

 

 

Window.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Top.png

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.

ObjPropsWrong.png

Link to comment
Share on other sites

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.

ObjPropsWrong.png

 

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

  • Upvote 1
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share