Joe_Carrick

Members
  • Posts

    11881
  • Joined

  • Last visited

Everything posted by Joe_Carrick

  1. "Area="+referenced.area.round(2).to_s+" Sq.Ft." Evidently CA only implemented the short form .to_s
  2. Greg, try this: "Area="+referenced.area.round(2).to_str+" Sq.Ft." This is called String Concatenation. There are 3 Strings in the above line and they get added together "Area=" referenced.area.round(2).to_str " Sq.Ft." to form a single output String. The .to_str in the second line converts the numerical value to a String so they can be added together.
  3. So maybe a "batch" system. ie: Update all Section/Elevation Views in the Layout would be nice?
  4. I can't think of a reason why I wouldn't want the Layout updated to match the Plan. Maybe it would be best if it was a "Preference Setting". Of course there is always the problem of what the current Render Technique and Options are in use for the Section or Elevation View. That could be a problem if the same Camera was being used for different views sent to Layout.
  5. Note: Automatic Save to Layout of Elevations and Sections is something that's been asked for - a lot !!! I don't know if CA is working on that or not. We can hope.......
  6. No, that's the way it works. Note that I said CAD (lines, arcs, text, dimensions, etc). IOW, as long as you are just doing labeling, dimensioning, etc in an Elevation or Section View it isn't necessary to "update" the Layout. OTOH, if you make changes to the model such as moving a Door, Window, Cabinet, Wall, etc then you would need to open any effected Views and save/update Layout.
  7. All CAD changes made in Plan are automatically updated in Layout. But you have to have the Layout open. My policy is to open the Layout whenever I open a Plan. That basically insures that almost everything I do in Plan gets updated in the Layout. The only problem I know of is Sections and Elevations if the model is changed. Those have to be opened and saved to update the Layout.
  8. Larry, I'm a bit older than you - but I learned to program about 35 years ago when I was only about half as old. Still, I am learning new tricks every day - keeps me feeling young.
  9. Actually just got in a hurry and forgot to zip.
  10. Larry, I'm proud of you........... See, even HumbleChief can learn new tricks.
  11. Here is an new set of macros. This one will recognized deleted vents as well as update when you open a new Plan - providing the new Plan has any Vents and their Labels are displayed. Foundation Vent Macros.zip
  12. PSolids (actually any solid) can be connected with an arrow pointing inside the area, whereas a simple Polyline will need to be connected to the edge. In Richard's video he is using a "Cross Box" which isn't just a simple Polyline - it has a "Fill" which also allows the arrow to connect to the interior - but it's not as persistent a connection as you get with a Solid. btw, I posted this a month ago - before Richard's video.
  13. The letters after the = are the left square bracket "[" and the right square bracket "]"". These should be just th the right of the "P" on you keyboard.
  14. Yes, but I have it reading specifically named files in my Project Folder. The data I'm loading is various Consultant Names, Addresses, Contact Info, etc. There is no reason that can't be set up to the data you want to retrieve. Basically each named piece of data is just a line in a text file. Edit the Text File, read it from Chief with a macro and the data will have been updated in Chief (I would assign the data to to Ruby Global Variable that various macros would use to perform calculations and display). In order to set this up I will need to know something about your Project and Layout File organization and what data you need to have available for your macros. Then I can give you a cost for whatever level of assistance you need. If it's properly set up it will only take a couple of macros - but one of them would need to be very custom.
  15. Mick, There is a Global Variable $Vents which contains all the Vent Areas from every Plan that you open in a Chief Session. Each one is numbered so that they do not get duplicated. However, if you had a Plan with 4 Vents and the 4th Vent is 2 sq. ft ---- and then open another Plan that only has 3 Vents, That 4th Vent is still in the list so it's 2 sq. ft is included in the total. There are 2 ways to deal with this: 1. Close Chief so that the contents of the variable are cleared 2. Close the 1st Plan, Open the 2nd Plan then open the Ruby Console and type $Vents = [] which clears the list. I have not been able to find a way to make this process automatic yet, but I have some ideas for the future. BTW, you could put that command in another macro which you could access via Text Macro Management but I think the Ruby Console is easier. The other thing you should do is select all the Vents, open the dbx and in the Frame Panel set everything to 0 - you can also uncheck "Has Frame". The Calculations depend on getting rid of the frame.
  16. Yeah, that would do it. Essentially when you drag a window vertically in 3D thru a Floor Level - Chief puts the Window on the Floor where it thinks you want it. Too smart for its own good.
  17. OK, Then Place them in the Stem Walls (Plan View). That way they show on the Foundation Plan rather than the 1st Floor Plan. You can set the height to whatever you need. If you have a goofy looking hole where the vent isn't supposed to be - Rebuild 3D.
  18. Scott, A Louvered Window is not the same as a Louvered Vent - and it's definitely not the same as a Screened Vent. What if you actually want to have a Louvered Window. I realize those are generally not permitted today - at least not here in SoCal - but they are in some places. Then you would have the problem of it probably showing up in the Vent Schedule. In order to utilize the macro that I provided there needs to be a way to identify that the object is in fact a Vent. The type_name attribute for Windows is the most logical way to do that. There are other possibilities but none that is quite as simple. That macro can even be placed in the Default Window Label and all new Vents will be accumulated - but other Window Types will not be effected (ie: Their Labels will not be changed and they won't be counted as Vents for calculation of the Total Vent Area.)
  19. OK Perry, in your case I assume you are using the "Foundation Vent - Screened". Set the Symbol y origin to 1". Place the Symbol in the 1st Floor Plan Set the Top Height above Floor to -2" If that doesn't get it for you - at least post a pic and the Symbol dbx. or you could post the plan.
  20. I don't think Chief's Library Vents were intended as Foundation Vents. They look more like Attic Vents.
  21. It depends on how much room you have on what drive. I have 3 different system: 2 of them have relatively small C drives and very large D drives. On those 2 I have everything on the C drive except my Projects. On the other system I have a very large C drive so I have everything on that drive.
  22. I would suggest y origin values for: Foundation Vent - Screened y = 1" Foundation Vent - No Frame y = 8" (or whatever your Stem Wall thickness is.
  23. Scott, Sort of...... One thing to make sure of is that you are on the Foundation Floor when you place them. The one with the Frame evidently needs it's y origin modified so that it sits where it should relative to the wall. I may have been playing with that value before I posted the Symbols. A lot of the appearance and how they fit depends on the Window dbx - these are after all, Window Symbols and are subject to the whims of Chiefs' Windows dbx. ps: Once you have the settings right, edit them directly in the Library.
  24. It would really be nice if we could set that up and have Chief repeat the whole thing "On Demand".
  25. Here are a couple of Foundation Vent Symbols I created that IMO are more appropriate than what Chief has in the Core Library. Foundation Vents.calibz