Joe_Carrick

The key is to create new Annoset and/or Layer Set as desired. Then use "Save Plan View As" to create a new Plan View. Make sure you reopen the prior "Plan View" and before saving it. This will insure that it isn't inadvertently changed. Plan Views do not provide for different positions of dimensions, etc. They simply provide a way of saving the Layer Set, Annoset, Current Zoom, Floor Level, etc.

Hmmmm.... That's not the impression I got at the time. We went back and forth over this issue for quite a while. Sorry if I misunderstood.

Scott's detail is just a CAD Detail. I complained about the MonoSlab when they were first introduced. Scott claimed we could get the Footer width, height & offset along with the Stemwall thickness and height all done automatically. It just isn't possible IMO. CA never responded and I gave up. This detail is really common in the southwest (SoCAL, Arizona, Nevada, New Mexico - and probably many other places). CA really needs to look at this. I basically agree with Michael that the only way to do it currently is to draw a standard stemwall foundation with a slab at the top. I recently had an engineer insist on a stem wall the full thickness of the footer. He was born raised and educated in the northeast and had no real experience with monoslab construction. The amount of concrete saved with Scott's detail is substantial, particularly when the stem wall gets taller.

Michael, I agree with you. I was probably using the macro rather than the attribute. But it's just really weird that the schedule number attributes don't work in the schedule unless you use them directly. Placing them in a user macro in the OIP field and then adding that field to the schedule always returns zero.

Mark, I'm not sure I buy Brian's explanation. I've experimented with other "Object Specific" attributes/macros that work in TMM but not in a Schedule. They generate errors in the Schedule when used within a user macro. That leads me to believe the macro isn't referencing the actual object at that point at all.

Maybe Chief's built-in macros (Global and Object): Are not Ruby macros at all but rather hard coded functions just returning text. That would explain why they don't work as we would expect.

The problem is with "Object Specific" macros used within user macros. Other attributes work fine - at least in most cases.

Back to the original problem. The simple_schedule_number is an "Object Specific" attribute - which works for owner as expected. CA evidently has a special connection for it's "Object Specific" macros to force them to work within a Schedule but when we use those in user macros that connection is lost. Within a Schedule a user macro finds the Schedule itself as the OWNER, not the ROW_OBJECT. Consequently it fails to provide the correct answer. We probably just need a "Object Specific" context in TMM to make it work. I've been asking for a "Room" context for a long time - but it's still not available. Maybe if OWNER when used in a schedule just referenced the ROW OBJECT it would work properly.

OIP fields are text automatically. If you want to get their numerical value you need to do that in your macros.

That's as bad as watchin a Tennis Match sitting on the sideline.

By making the leader line connect to an object within the room it will work

No, but I have determined that you are correct that the leader needs to connect to an object rather than the room. Even a very small solid will work but a fixture, cabinet or piece of furniture would be easier. Material Regions don't work. IMO, connecting to the room should work

Michael, Can you post a macro that works under those conditions?

1. Place a RTB outside of the exterior wall and add a leader line to a room. 2. Insert a user macro in the RTB that references a room attribute such as: room.schedule_number I don't get any result. When I put the RTB inside the room it works.

Note that it won't work with a referenced (leader line) condition. I need to report that.

I just discovered that the room attributes are not available with Rich Text when a Leader is being used. IOW, referenced macros don't get the room data.

Yep, In fact it's now possible to have a macro that creates a vertical schedule for an individual room. ie: one column and multiple rows. This is something I asked for several years ago. CA still hasn't provided that directly but with this new functionality we can essentially do it ourselves. The key is that we now have access to all the room attributes in user macros vs the limited set CA provided in the object macros.

Attached is a macro that when placed in a Rich Text Box creates a Room Label consisting of the Floor, Room Number & Room Name. Example: 101 - ENTRY 102 - LIVING 103 - DINING 201 - MASTER BEDROOM ETC. Enjoy room_num_name.json

None that you are using - at least not at this point. I did find a problem with my X10 Wall Legend macro which I've re-written for X11. The X10 macro basically locked Chief requiring an "End Task". If you see this type of behavior anyplace let me know.

Don't hold your breath. It's not on my priority list.

I'm not sure yet but I think I'll be able to put together a Note Schedule that contains the results of macros referencing Room Attributes in the custom fields of the Notes. It may or may not be worth the effort.

I'm not saying a lot about X11 - but I'm grinning a lot because so many of the new features are things I've been asking for. The one thing I really wanted was an OIP for ROOMS and FRAMING OBJECTS. Maybe they'll still be able to get those in for the final release. If not then I really hope they get them in X12. I've had to do some revisions to some macros for X11 but the results are superior. I had one macro that worked nicely in X10 but brings X11 to a virtual standstill. I still haven't been able to identify exactly why, The new Notes have the room attribute and also the OIP so there's actually a way to get part of what I wanted.

Yep, those custom_fields make a world of difference since we can now access them and perform calculations, etc.

HI Mark, Did you notice the new attributes for panels and inserts? At least I think they are new.

That's the correct way to do it.