Joe_Carrick

Ok, then here's an example: The question becomes "What good is the non-CAD Style size in Rich Text My suggestion would be to just eliminate that option entirely.

My question really is: Why should it be any different than regular text? Why the differences in the size?

I'm using Chief Blueprint as well as Arial.

Why is CAD Style so much larger ? When I use the CAD Style (Check Box in the Rich Text dbx) I get text that's approximately 50% larger than the size would indicate. This is not true with regular text which doesn't have this option. I've read the help file description for Rich Text but it doesn't make sense. If I want Rich Text that's about 9" tall and I use CAD Style then I really need to set the size as 6". IMO this is a total screw-up. I prefer to set the size and have it be accurate and CAD Style seems to be something totally wrong.

I always put my drawing title, scale, etc in the Plans, Sections, Elevations and CAD Details. In the past when I sent a view to Layout I would always need to "Suppress" the Layout Box Label. This was an annoying extra step for each Layout Box. So I did a little searching to see if I could find a Default that would allow them to be automatically suppressed. NO SUCH LUCK. So I then looked at the Object Layers for the Layout Boxes and found that the Label has a separate Layer. That Layer can be turned off for display in the Template. What I haven't figured out is where the Label Layer is assigned. I know I must have done so at some time in the past but I can't find it now.

OK, I figured out that somehow my Main Layer of the Interior Wall Type had been changed to a non framing material. I have no Idea how that happened but once I changed it back to Studs, 16" OC everything is fine.

No, it's off but my interior walls are stopping at the exterior wall framing.

I can't seem to find where to turn off the breaks between framed walls. IOW, where one wall type intersects a different wall type. I never had this problem before X11.

I use a macro that copies the entire Project Folder and renames everything to a new Project Name, including the Layout and the Plan File.

Adjust the transparency or add a little bit of color to the Glass Material

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.