AgChief Posted February 15, 2017 Share Posted February 15, 2017 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 Link to comment Share on other sites More sharing options...
Joe_Carrick Posted February 15, 2017 Share Posted February 15, 2017 John, Try this: arr = owner.header_elevation.round().divmod(12) "#{arr[0]}" "'-" "#{arr[1].round()}\" H.H." Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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. Link to comment Share on other sites More sharing options...
AgChief Posted February 15, 2017 Author Share Posted February 15, 2017 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. Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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. Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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 More sharing options...
AgChief Posted February 15, 2017 Author Share Posted February 15, 2017 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. Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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 More sharing options...
AgChief Posted February 15, 2017 Author Share Posted February 15, 2017 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 More sharing options...
Joe_Carrick Posted February 15, 2017 Share Posted February 15, 2017 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 More sharing options...
Joe_Carrick Posted February 15, 2017 Share Posted February 15, 2017 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 Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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... Link to comment Share on other sites More sharing options...
Joe_Carrick Posted February 15, 2017 Share Posted February 15, 2017 I agree with Michael. Of course he has exaggerated the Top and Bottom Rough Opening values - but it does illustrate the point. Link to comment Share on other sites More sharing options...
AgChief Posted February 15, 2017 Author Share Posted February 15, 2017 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 More sharing options...
Joe_Carrick Posted February 15, 2017 Share Posted February 15, 2017 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 More sharing options...
AgChief Posted February 15, 2017 Author Share Posted February 15, 2017 Thanks, Joe! I've reported it too so maybe we'll get a quick fix. Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 15, 2017 Share Posted February 15, 2017 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 More sharing options...
OkcDesigner Posted February 17, 2017 Share Posted February 17, 2017 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" Link to comment Share on other sites More sharing options...
Joe_Carrick Posted February 17, 2017 Share Posted February 17, 2017 I received a notice from Brian at CA that he could reproduce the error and logged the issue. 1 Link to comment Share on other sites More sharing options...
AgChief Posted February 17, 2017 Author Share Posted February 17, 2017 Joe, I dropped your name when I contacted tech support, so that's probably what sped things up! Link to comment Share on other sites More sharing options...
AgChief Posted February 17, 2017 Author Share Posted February 17, 2017 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. Link to comment Share on other sites More sharing options...
Joe_Carrick Posted February 17, 2017 Share Posted February 17, 2017 Here's my version of Object Properties. It works much better IMO. _Object Properties.json Link to comment Share on other sites More sharing options...
Alaskan_Son Posted February 17, 2017 Share Posted February 17, 2017 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 1 Link to comment Share on other sites More sharing options...
AgChief Posted February 17, 2017 Author Share Posted February 17, 2017 18 minutes ago, Joe_Carrick said: Here's my version of Object Properties. It works much better IMO. _Object Properties.json Thanks, Joe! Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now