Joe_Carrick

Please send me a PM with a more detailed description of what you want.

I am pretty sure that would work - but I just prefer to use the model itself as the data source. I set a timer on my data accumulation macros so that they stay updated properly.

In order to do ventilation area calculations using macros (which I have done) it requires that you: Collect the total areas of Crawl Spaces, Basements, Garages & Attics Collect the total areas of all Vents and they must be identified as to what type they are The Types would correspond to the above listed spaces The Types can be based on room names containing specific words. All of the above can be done using macros within the Labels of Rooms & Vents. The calculations of required vent areas may vary depending on the locale. The NFA is dependent on the vents being used and as such need to be plugged into the macros that display the required and actual vent sizes.

Note that this is in reference to Classes must start with a Capital. User Macros are not generally: Classes which must start with an uppercase character Methods which must start with a lowercase character Constants which must start with an uppercase character In fact, a User Macro is just a Ruby Script that uses Ruby Classes and all their Objects. It can even start with a special character such as the underscore. I'm not sure how Chief's implementation of a macro as a method would fit in that scheme.

Hi Kirk, I just reviewed both of those links and neither of them specifically identify a required upper/lower case requirement. As far as "methods" are concerned, I use define them as Class Methods as the first link shows. User macros that act as "Methods" would still need to be used carefully within other macros simply because they need to belong to the same "Class" and that requires the user to understand that fact. IOW, a "Method" that performs math calculations must use variables that are limited to numeric values and one that performs string manipulation must use string variables, etc. Ruby already includes virtually all the Classes and corresponding Methods such that defining additional macros to act as Methods is just not needed. I would be far happier with Chief providing all the Object Properties as available attributes. X11 has improved this with the groups (arrays) for Walls, Floors, Ceilings and Roofs, etc but there are still hundreds of values we can't access.

Kirk, AreaRounded or RoundedArea will also still work so long as the object the macro is evaluating has a readable area. I just don't like the software unnecessarily forcing this on me. It's OK to tell me (with my ability to over-ride the message) but it's not cool to force a convention that I don't want.

Basically so that the annotations (dimensions, text sizes, arrow sizes, etc) would be what you want automatically. Of course, you can have defined Annosets and Layer Sets to switch to, making that happen. So the only real advantage would be the elimination of a couple of mouse clicks.

FWIW, I now name my macros using lowercase but almost all of my existing macros (several dozen) were capitalized and in I retain those names - even when I make edits. When I need a "method" I define it as such in an "rb" file which can be loaded and is then available for use within any other macro.

Renaming isn't really mandatory. If you do allow Chief to rename them then everyplace you have used the Uppercase version will no longer work because that macro will no longer exist. When Chief asks (suggests) that they be renamed - I just select "Ignore". It's only in cases where you want to call a macro from within another (as a "method") that it needs to start with a lower case character. For me, that's almost never. BTW, I think when CA initiated this "Renaming" it was a big mistake. It's a real PITA to deal with. Ruby is case sensitive and conventionally uppercase is supposed to be reserved for "Constants" it isn't mandatory to make everything else lowercase..

I can see how it would be useful - and I would probably use it. OTOH, I generally just select the desired Annoset immediately after creating a orthographic view and save the camera. It would be nice if that wasn't necessary.

Larry, Do you have an appropriate object selected? ie: an object that has an "area" attribute.

Yes, the so called "Layer Set Defaults" should really be "View Type Defaults" and include columns: Annoset [Define] Layer Set [Define] Basically functioning to provide selection of either or both and define/edit those defaults. As Eric said, if the selected Annoset specifies a Layer Set then that should over-ride or specifically change the Layer Set in the dbx. That is always my preference but some users prefer otherwise - and "Saved Plan Views" and "Saved Cameras" over-ride everything else.

Larry, As Edward R Murrow used to say: "That's the way it is." You can define Annosets for Sections and Elevations and switch to one of those but there isn't any way to make a new Section or Elevation automatically use a specific Annoset. This would be a good one to request.

On both Monitors?

Joe, Have you checked to make sure NVidea Graphics is being used rather than the "OnBoard GPU"?

Maybe the "Mod Squad"? Of course if you aren't at least 60 years old you wouldn't have any idea what that is.

The question is why do you want to put the old plan into your new template. There are several options depending on what you want to accomplish. One option is to export all the Defaults, Layersets, Annosets, Line Styles, Text Styles, etc from the Template and then Import them into the old plan. That way, you won't lose any Sections, Elevations, CAD Details, etc.

Use multiple stretch planes only if you want the symbol to stretch just at those specific locations. Example: a 6 panel door - use 2 stretch planes on the x axis & 3 stretch planes on the z axis (centered on the panel area) That will cause the rails and stiles to maintain their widths. It has always worked this way. The difference is that now you can see the stretch planes and manipulate them with the mouse.

Hi George, I haven't either. This particular macro uses a global variable that CA modified for X11. I had to do a little work to make it work correctly with the new data. BTW, Thanks for your support - I really do appreciated it.

Anyone who has my _Chief Version macro and is using Chief X11 please contact my and I will send a revised version. In X11 CA changed the content of the S" Global Variable which I use to retrieve the Version. I have a new version that works for X11 and should work for all future releases.

Michael, When would you want the Plan Notes Schedule in a CAD Detail? If just for that particular detail then it's the same thing (view specific) isn't it? My concern after working with them quite a bit is that separating the Plan Note Schedule from the View where the Callouts are located gets very messy. It's difficult to force them to be relative to one another. If you put the schedule in a separate CAD Detail then it's difficult to identify which schedule should be sent to what page/view in the Layout. Most Schedules (Cabinet, Door, window, Appliances, Fixtures, etc.) don't have that problem because they are project wide (or at least floor wide). Note Schedules are a different animal.

My preference is to have them in the Saved Plan Views, Sections, Elevations, etc. Specifically the same view that the callouts are located in. It just seems a lot easier to control that way.

Here's the way to deal with this: In the Annoset edit the NOTES Tab. Set the Layer for that particular Note Default. Maybe make some additional modifications to the Layer Set Then it should be automatic after that. Just change the Annoset and it all falls into place.

Yes, Preferences are a totally different thing. They really don't have anything to do with "Templates" which just open File Content.

OK, here's what I get when I open the New Saved Plan Template. All of the Plan Views, etc are there - only one Plan View was initially opened.but that was the state when I saved the Template. Note that expanded the Project Browser & opened all those views.