Joe_Carrick

Members
  • Posts

    11881
  • Joined

  • Last visited

Everything posted by Joe_Carrick

  1. Basically, you can't have a higher ceiling height because a room above has a floor height that's to low to allow the higher ceiling. Raise the Floor above and then you can edit the ceiling below. It's best to work from the top down so that you avoid this kind of conflict.
  2. It would be appropriate for these requirements to be available in the Framing Defaults. ie: User specified with an OOB default matching Table R602.7.5 Note that for energy purposes the studs are often 2x6 or greater so the actual structural need may be less than what Table R602.7.5 specifies. I do my own structural engineering to determine what is needed for wind loads as well as gravity loads. Depending on the location of the header vertically vs the height of the wall that can vary dramatically. Also, when using Simpson Strong Walls that Table isn't appropriate so even if CA adds the requirements to the Framing Defaults they should be able to be over-ridden.
  3. I'm not sure exactly what you are saying. If you right Click on the "Library" tab of the main menu bar (this is not a "Tool Bar") and the "Library Browser" shows a check mark then it should be visible someplace. Another way is to move the mouse cursor over the "View" tab you will also see if the "Library Browser" is checked. If not, click on it to make it visible. "Library Icon" is something I don't understand - as far as I know there is no such thing in Chief. BTW, what version of Chief are you using?
  4. Hi Michael, Yes, I have also adopted that methodology - for certain cases. However there are limitations when more than one object is in that position in the schedule (multiple copies of a Note for example) and you need to accumulate values. In that case, you may need to store several sets of data by using a multi-dimensional array. It can get complicated. That's why I made the suggestion of being able to access the displayed Schedule Content from within a User Macro. That would make it much easier.
  5. That's because X11 is still in Public Beta - or your SSA isn't current. If your SSA is current the Public Beta of X11 should be in your digital locker.
  6. You should also check out X11. There are some really great new features regarding Textures and Patterns - including offsets as well as auto pattern generation from texture.
  7. No, Chief Architect Version - which in my case is: X11 (64 Bit) or the full name: Chief Architect Premier X11 (64 bit)
  8. No, because there's no way to get the data from the Schedule. The only way to accumulate areas is to utilize the Room Labels or the Label of Polylines. It can be done with a macro but it's not easy to do because it's a running total and has to be reset periodically so the same areas are not added repeatedly. That means setting a timer to limit when the label macros update the data is critical.
  9. Yes, I know that but I'm not sure why this needed to be done. Was it primarily for the Materials List? Note that the Ruby Tutorial is a method that's loaded by Chief at startup. This is created within an "rb" file using standard Ruby "method definition". As I stated previously, any methods that need to be created can (and IMO should) be done specifically as Class Methods by defining them as such.
  10. Please send me a PM with a more detailed description of what you want.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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..
  19. 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.
  20. Larry, Do you have an appropriate object selected? ie: an object that has an "area" attribute.
  21. 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.
  22. 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.
  23. Joe, Have you checked to make sure NVidea Graphics is being used rather than the "OnBoard GPU"?
  24. Maybe the "Mod Squad"? Of course if you aren't at least 60 years old you wouldn't have any idea what that is.