Joe_Carrick

That's because CA keeps making changes to their Catalogs. You can of course skip the updates and just do them at a more convenient time.

Eric is correct that it works in a text box - but you have to put it there as a macro evaluation.  ie %...........%.

You can even use a RTB and get all sorts of formatting.  The advantage however of using a custom macro is that it can get data from the owner or referenced object and use that to return results.

The wall in the 6th row is controlling all the row heights.  Why is that wall so thick?

I just tried the following in the Ruby Console:

• y = 450.00 ; x = Math.sqrt(y).round(4)      ---> 21.2132

It works fine.  However, the data in the parentheses has to be numerical.  Otherwise you'll get an error.

Also note that Ruby is case sensitive.  So as Eric said, Math works, math doesn't.

You would need a custom macro.  It's not a difficult one to create.

This is why I don't like the Schedule method.  The Detail Callouts should be based on their position on the Layout Page automatically.  Then any Plan Callouts linked to the view sent to Layout will automatically be correct.

Detail Callouts should be based on their position on the Layout Page & Plan Callouts should always be correct.

Convert them to Symbols.  I would use "Exterior Fixture".  Then you can use a Schedule.

I use a custom sheet size for my Interior Elevations.  Typically 4" tall x 7-1/2" wide with a corresponding CAD Box (invisible linestyle)

When I send the view to layout it's automatically that size and will snap to other layout boxes.  The Layout Box can be resized if needed but I only need to do that for the width in most cases.

I also have a default set for my layout boxes so they are labeled to match the project browser name.

Actually using the "Match Properties" tool works.

OTOH, the "Object Painter" tool really should match the "Arrow Style". Submit a request.

11 minutes ago, EDCsharon said:

there's nothing like sleeping on crisp cotton sheets air dried

Unless you have birds that perched on the clothes line and left their calling card.  

Use a "Working Layer Set" with the "layout lines" displayed and a "Print Layer Set" with them not displayed.

That's more understandable with the above picture.

6 minutes ago, JKEdmo said:

 

For your consideration --

 

If the framed wall stands proud of the stair, one option would be to leave the full-height doors like shown with the door leaves concealing the sheet-rocked stair underside.

Assuming the doors swing outward.

Otherwise it will be a problem because the one on the right will not open no matter what the shape.

1 hour ago, basketballman said:

Always been minimum of 4" height difference between garage and main living area.

Code cites Fire and also flood prevention ..

Can you reference the Code Sections for this?

The CRC (California version of the IRC) only specifies a slope for drainage.  I can't find anything about a height difference.  The 4" height difference was a requirement at one time in the old "Uniform Building Code" but I'm not sure if it was even required in the last UBC.  I don't think it's ever been required in the IRC or any version thereof.

Fire protection is another issue entirely covered by Doors and Walls.

When will the X15.3 update be available?  I sure hope it will be this month.  

--- and of course that it includes all the NVPs I've asked for. 

Just use "Text" or "Rich Test" and drag the diamond icon to create the line with arrow.

Search for Roll Up

I posted one in a thread that comes up.

14 minutes ago, Hautetxinteriors said:

Yes, it has the show open off. 

Have you "Updated" the view?

Make sure the "Show Open in 3D" is off.  

It could be done with a custom macro in a text box with an arrow connected to the cabinet.

For a more comprehensive automatic method a custom macro would have to be created that would rely on the name of the layerset so that the label would only display that in an elevation view.

OTOH, the "Comments" field can be shown as a column in a Cabinet Schedule.  That's probably the best way to deal with it.

37 minutes ago, KenL-sdd said:

@DBCooper I only want to remove a portion of the fascia, not the entire roof. I think we need a menu to turn off on selected edge like gutters.

Thanks for your input.

Ken,  That setting can be for an individual roof plane.  If necessary you can break a roof plane to get just a portion of the edge.

My preference - if possible - is to have about a 5-6 ft level area and then a step-down that acts as a wheel stop.  I usually have the door between the garage and the interior at a location so that's possible.

Rene,

$Global variables can be assigned values from an object - but they are not attached to the object.

OTOH, you can assign any value (including a $Global) to any field in an object's OIP.  Just be aware that if the $Global"s value is change then that OIP field will also change.

I have some macros that rely on the current view Layerset name.  Unfortunately that is assigned to the object when it's created so it's not going to be available for the object.  My solution is to place an invisible text in each view with a macro to assign the Layerset name to a $Global.  That $Global will always be the name of the current view Layerset as long as the Layerset of the view isn't changed.

I had requested years ago that Chief add a $Global for the current Layerset but they simply added the NVP for each objects layerset. 

To store a value in an object use an OIP field.  

To assign a value to a $Global use an objects NVP or any other value you want.

BTW, a $Global can be an array if you want to store a lot of different values.  $p[n] where n is specific to the object.

A Hash could also be used, depending on how you want to be able to identify the values for retrieval.

For an asymetric door you will need 2 versions.  This is not a matter of "Change Hinge Side" - rather it's a matter of the actual swing.

3 hours ago, Renerabbitt said:

I fixed it, and it is a bug. If you added something to a style palette that contained a macro in its label, that macro will always remain. You have to make an entirely new style palette. You cannot overwrite the existing style palette because the label macro remains. Interesting because there is no reported value for label in Style Palettes

I think I understand.  It's kind of the same as the previous problems (prior to current X15 version) with symbols stored in the Library.  What object did you include in the style palette?  I assume there wasn't any way to replace that object with a current X15 version object.