Joe_Carrick

Actually, there were 10 versions prior to that and some versions took more than a year. Chief is an extremely complex application that makes the process of creating designs and construction documents much easier, more accurate and faster. As an Architect that means I can do more projects in less time and can have confidence in the quality of the finished product. The Home Designer products are limited in scope and can work for non-professionals but for design professionals (those using the software for there business) Chief Architect is a much better choice. You should look at the feature comparisons of Home Designer vs Chief Architect. That will give you a better idea of why the cost is so different.

Glenn, Try to reflect a quarter-round arched window vertically.

There really needs to be a "Bottom Arch" or the "Transform/Replicate" tool needs to be able to reflect a window vertically. That tool insists on reflecting an arched window horizontally which IMO is a BUG.

Taking an X11 Symbol to X10 isn't that difficult. The process is to: Export the X11 Symbol to 3DS Open X10 Import the 3DS file But if you have X10 and SSA you can just upgrade to X11

Can't you just group select all of the #7 notes and edit them all at once?

If you use your Scale Bar in a Plan, Elevation or Section it will reflect whatever the current scale is. There shouldn't be a need for more than one Scale Bar. It is then a part of what you send to Layout and will be correct for whatever scale is used in the Layout.

In many case that may be true. However, having a separate Annoset allows you to select the Plan View and immediately start working with the appropriate defaults for that Plan View. In addition, the Annoset can activate the appropriate Layer Set. It just saves a little extra time and grief.

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