AgChief

Ruby macro evaluation error, x9 final release

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

Share this post


Link to post
Share on other sites

John,

 

Try this:

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

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

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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. 

Share this post


Link to post
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%?

Share this post


Link to post
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.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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. 

Share this post


Link to post
Share on other sites

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"

Share this post


Link to post
Share on other sites

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

  • Upvote 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

  • Member Statistics

    27499
    Total Members
    6254
    Most Online
    Bren0625
    Newest Member
    Bren0625
    Joined
  • Similar Content

    • By ccarpenter18
      In X12 I've noticed that when using Structural Member Reporting in a material list, the price column in the list does not appear to be sensitive to whether a "per unit" or "per length" calculation is being performed by the material list.  In both cases, the material list appears to use the same Price variable in the Component Panel of each object.  Does anyone know of some Ruby scripting that could be used to correct this?  Off hand, I'm thinking of a macro inserted into the Price variable on the Component Panel of each structural member that would use the Material List row context to report a price that depends on how the row wants to use the Price.
    • By wjmdes
      OK, so today I learned that Legacy is just a fancy term for obsolete.  See, I do know how to search  
       
      I have numerous macros, from others and some I wrote.  Has there been any enhanced documentation regarding what "migrating" is going to do to my macros and what I can expect? Or how to fix issues? Is this going to put the brakes on my workflow?  I know enough to write small macros for menial tasks, but I do not have an extended knowledge.
       
      Or is this just not a big deal?
       
       
    • By jessde
      x9   intermediate skills
      Can someone explain how to configure text in other than a straight line?
      Thanks for any help offered.
      J
    • By community
      Hello,
      Just throwing the question out here: Is it possible to write a custom script for X10 to make the program export a custom materials list with some calculated fields and some custom formatting, like a header with our logo?
      If so, would anyone have an idea where I could turn to have this done for me?
       
      Kind regards