Joe_Carrick

Larry, I do not use %scale% in the Plan. I know that Chief recommends that macro because it corresponds to the printed (or displayed) scale. I prefer the scale sent to Layout. -so- I use %view.name% in a Text Box in the Plan and Scale: %box.scale% in the Layout Box Label.

OMG..... .... I would never have done it any other way.

Another way to do this is to use a Full Height Cabinet with an opening for the Refrigerator. It can all be done in the cabinet dbx.

I just use a Text Box with the Text I want - in the Plan. That way I can set it to the font and Size I want. You could use %view.name% Plan if you want but the names will be: Foundation Plan 1st Floor Plan 2nd Floor Plan 3rd Floor Plan Attic Plan It works, but it has some limits. It would be nice if Chief would allow the Floor Plan Names to be edited in the Project Browser - but I don't expect that to happen any time soon.

Larry, I use the Layout Label to show the scale: Scale: %BOX SCALE% In most cases I place the following in the Plan views: %view.name% which corresponds to the name in the Project Browser. Most of the views (CAD Details, Cameras, Cross Sections, etc) can be renamed in the Project Browser. The Floor Plan views can't be renamed so for those I just use Text. The macros shown above are Chief's OOB macros so it's just a matter of setting it up in your templates. Then the naming is pretty much automatic.

The Layout and the Plan should be in the Project Folder. But secondary Plans located elsewhere can have views sent to that Layout. I have several secondary Plans that contain nothing but Standard Details. My standard Layout has many of those details already and for each project I will send additional details from those plans as needed. When I create a new project from an existing, I don't have to re-link those because they are in a folder that doesn't change.

Very true, Materials, Textures, and a variety of other things can get very cluttered. Properly clearing out all unnecessary junk is critical. Since I use separate Plan Files for Details, and only use CAD Details within my Project Plan for Schedules, some Text Boxes for standard notes, etc there isn't much to eliminate. My Plans usually don't exceed 50 MB. Of course if you start adding a lot of 3D Symbols, Terrain, etc with high-surface-counts you can jack that up very quickly. OTOH, when you strip those from the plan it should go down pretty fast.

Larry, The Layouts never really get that big. Most of what's in a Layout is just 2D graphics. The Plan will grow or shrink depending mostly on the 3D objects contained in the model. When you strip a Plan down to almost nothing, it will become fairly small. There will obviously be some data that remains but I haven't found a case where it creates a problem.

Michael, Not much different at all. You can save any Plan as a Template. You can save any Layout as a Template. Usually you would save those to Chief's Template Folder but even that isn't mandatory. My system is designed to copy the entire Project Folder Structure along with everything in it and do the renaming of the Layout and Plan and any auxiliary files in a single step. The macro that does this is located in a CAD Detail in the Layout. I just open the CAD Detail, provide the new Job Name and everything is done. Complete New Project ready to go.

I use a slightly different approach. I use any previous Project as a set of Templates. My system - macro based of course ;) , copies the entire folder structure of whatever Layout/Plan I currently have open and renames the copy to the new project name. Then all I have to do is relink the new Layout and clear out the Plan - as much as needed. Sometimes there are some areas of the Plan that can be kept, but usually I delete everything except the Terrain Perimeter, CAD Details and Cameras. Any secondary Plans (Detail Plans for example) linked to the Layout are automatically linked to the new Layout so I'm all set to go.

I have my files on Dropbox. This works without delay because there is an actual "Dropbox" folder on my HD.

I would check your AV settings and make sure Chief Files and Folders are exempted. That may not be the problem, but it might be.

The only way I know of doing that is: 1. Display them in 3D 2. Use the "Delete Surface" tool on everything except the object you want. 3. Convert what's left to a New Symbol Repeat the above process with each of the composite symbol to get each individual.

XOR is a programming logical comparison of 2 values. If both values are equal it evaluates as "true" If the values are different it evaluates as "false" Of course, this is pretty much meaningless to Chief Users. Programmers understand the term but it's pretty much gobbledygook to non-programmers.

You should not put it in page 0 or any other "template" page. In Tools>Layout>Edit Page Information select the desired page(s) and enter it there in the "Label" field.

Here's a "Pocket Door Pull" that works and doesn't protrude too far from the face of the door. Actually, I would prefer it be even closer (ie: flush) but IMO it's close enough. You need to assign it as the pull for both sides of the door. Pocket Door Edge Pull.calibz

Perry, Let's get back to post #1. We don't need to beat a dead horse with the "pocket". I am going to agree with showing the pocket. I just want CA to pay attention to the rest of the stuff as well.

This is one of those problems where since there are no casings, Chief has incorrectly eliminated the "Jamb". Of course the RO still needs to be zeroed out, but the door still needs a "Jamb", just like a window needs a "Frame".

Unfortunately, sometimes we really need to bring a plan forward from an older version. Technically, a Plan is no different than a Template. The only difference is that when you create a new plan from a template you have to give it a new name when you save it. The fact is that when we bring a plan or template forward it really needs to work 100% with the new version. That means CA has to internally modify the file structure to accommodate all changes required. Anything less is just not going to work.

I'm bumping this post. It was originally posted 3 years ago. AFAIK, only #7 was fixed to date.

Gerry, can you provide a link to the video about Fill Patterns? Never mind, I found those attributes - but only in X8. They don't exist in X7. So why did CA add those attributes to Polyline Objects in X8 but didn't add other attributes that would be much more useful? Such as fill_name

Gerry, I really don't want to use an external line style editor. We should be able to use Chief to do this. I agree we should have a readable & editable name field but until we do, the layer works for some things quite well.

To satisfy Glenn, I guess I need to start using an install program. Maybe that would actually be a good idea anyway. It would reduce the amount of time I have to devote to setup instructions.

Gerry, I tried using Line Styles and found the following: Chief's built-in Line Styles have names that are usable but user defined Line Styles have a different name (Ruby Attribute) than what the user named it. This makes it almost impossible to use custom Line Styles as an identifier in macros. As far as pattern_angle and/or pattern_spacing: Those attributes are not available to Ruby, so they can't be used. The line_weight is the only really usable attribute that makes this work properly. If you have some way of accessing other attributes not listed I would be delighted to know how. X8 added the Layer Name as an accessible attribute (for all objects) which has proven very helpful - but the ideal would be a name attribute for all Chief Objects.

Brian did confirm it - I haven't heard anything more from CA. It really should not matter, but the numbers are off by the thickness of the Floor Finish. It essentially is making the Stair that much too tall and results in the risers being a fraction taller than they should be.