Material Lists - Extract Qtys Into Layout

[tchomes]

Is there a way to extract the material list properties into a custom text box?  For instance, I always list the sqft of roofing area on my plans.  It would be nice if I could pick an attribute and assign it to the text box in my layout so I didn't have to open the material list and copy the number over to my layout.  Then when my roof changes slightly, I have to do it all over again...

 

Just a thought.  I usually list total sqft of countertops, roofing area, different flooring areas (tile, wood, carpet, stained concrete).  This is something that my builders love about my plans as it makes it easier for them to do takeoffs, but I would like to be able to automate this. 

 

I have not used the Ruby tool (not sure even what it is), but am I missing something?

 

Thanks in advance to all the experts out there.  Been using it for 10 years, but some days I get aggravated and come to the forums for help on efficiency.

Roy Homfeld

Tracy's Custom Homes

Farmersville, TX

[Joe_Carrick]

I use Ruby macros to do that.  You need to know how to use and write macros or maybe subscribe to my "Macro a Month Club".

[tchomes]

Thanks Joe for your reply.  Sounds like there is a way to do it.  Now I just have to figure it out.  Is there a manual on how to write macros?  I've written macros in Excel, but not sure what language Chief uses.

 

Roy

[Joe_Carrick]

Ruby is Chief's macro language.  It's more like basic than or similar programming languages.  Chief has simplified "tutorial" built in that you can access by opening the Ruby Console and typing "tutorial" <enter>.

 

Macros in Chief are created and/or edited using "Text Macro Management".

 

There a lot more that can be done than what the tutorial shows.  You can learn more by downloading "The Little Book of Ruby" and then checking out http://ruby-doc.org

 

There are also quite a few threads on the Forums that give examples.

[lbuttery]

Roy:

 

Chief uses Ruby

 

I wish they had chosen VBA but they wanted independence from MS

 

Chief's Ruby implementation is very limited

but still useful for labels etc

 

I've never used it as I was very disappointed with it when X4 came out

then I retired shortly after that

 

Joe is one of the main Ruby guru's

 

Lew

[glennw]

You could use the built in label macros to show the area as a label.

in the Roof dbx, go to Label panel...Specific Label...Insert...Object Specific.

Select the parameter you want displayed.

 

This way saves mucking around with custom macros.

[Joe_Carrick]

You could use the built in label macros to show the area as a label.

in the Roof dbx, go to Label panel...Specific Label...Insert...Object Specific.

Select the parameter you want displayed.

 

This way saves mucking around with custom macros.

True, but automatic calculations are not possible with the built-in label macros.  Only with custom macros can calculations be performed.

[GerryT]

interesting -- summing areas is one of the easiest things to do in Chief

 

Here's a video that might point you in the right direction

 

http://www.youtube.com/watch?v=NgWxXHnb1eI

[glennw]

Interesting -- summing areas is one of the easiest things to do in Chief

 

 

 

Why even sum them when the information is already available.

Here is one way of doing it for roofs without messing around with macros.

This keeps it nice and simple (I like the KISS principle) by using the Polyline panel in the dbx's.

Jerry - I guess this data is not available directly using Ruby?

I note that Jerry was saying that his macros need to be redone after a close and reopen of the plan - I reckon it's easier to copy and paste.

 

http://screencast.com/t/SOmJe4twc

[Joe_Carrick]

Sorry Glenn,

 

My Roof Macro Package is dynamic and once set up is a lot quicker.  It labels each roof plane and provides tables with all the individual roof plan data as well as totals.  You can view the video http://screencast.com/t/fDqTIdWZw1 to see 3 of my macro packages, including the Roof Package.  It's all done in the Roof Label.and is 100% updated and correct whenever the Layout is printed or displayed.

 

I think Gerry has another method but I think mine is easier since it doesn't require any "process" to get the data updated.  100% accurate and dynamic on the fly.

[glennw]

Joe,

No need to apologise.

I was just pointing out a very simple way to get those totals.

I personally don't want to keep track of and organise a multitude of macros to perform what are essentially fairly simple tasks.

 

I would probably be a lot more enthusiastic about these sorts of enhancements when they come as simple plug-in or app that I can install with one click and control with a graphical interface.

 

I admire you perseverance and the time you have put into the utilisation of Ruby though.

 

I was just looking at your video.

Can you easily control what particular roofs, areas or rooms are included in your tables, or do you have to have all roof planes, rooms and areas included?

[Joe_Carrick]

Joe,

No need to apologise.

I was just pointing out a very simple way to get those totals.

I personally don't want to keep track of and organise a multitude of macros to perform what are essentially fairly simple tasks.

 

I would probably be a lot more enthusiastic about these sorts of enhancements when they come as simple plug-in or app that I can install with one click and control with a graphical interface.

 

I admire you perseverance and the time you have put into the utilisation of Ruby though.

 

I was just looking at your video.

Can you easily control what particular roofs, areas or rooms are included in your tables, or do you have to have all roof planes, rooms and areas included?

It's a simple matter of having the macro in the Roof Plane's Label or not.  Each Roof Plane is set to a different line_weight (number) and that's the ID in the table as well as the Label in the Plan.  The macro also recognizes, labels and tallies the Roof planes as Existing, Demo or New depending on their Line Style.

[GerryT]

I guess  Glen was so determine to make his point that he forgot to actually watch the video(s) in which all the above was answered. But it was a good point.

 

For those that caught another issue, you do not have to only use line_weights as a identifier, particularly if you have to use and turn them on later. You can also use: pattern_angle, pattern_spacing, or line_styles.

 

I use custom line_styles as a means to name a target areas as in the line style name --- "Recreational area" ( the line pattern is the same as straight or still could be anything you want) and use the other fields to identify subsections of that area. No need to remember number codes and output is self evident with minimal coding. Very helpful if you need to separate identical objects by location -- front yard/back yard. You can also now use the object_type attribute to encompass many different objects and listings with just one macro - "one size fits all" thing. And I would say that if your macros need be 200+ lines long, your doing something wrong.

 

These are all ten minute additions that Chief has made over the course of FIVE YEARS since X3. Much more could be done, but many are just not open minded to learning a new approach to working smarter and to the extent of not even taking advantage of what is freely offered. Some seem to be intimidated that others might incur an advantage and seek to slow progress. I expect the same thing happened with the transition from hand drafting. It, indeed, is always the younger generation to see the advantage of new trends.

 

Having said all that, I do agree with Glen, that Chief does not want to lead in this area, and attempting to use a feature actively discouraged by them may be a futile endeavor if other options or software are available for now. IMNOHO-- this is the case, as Chief is emphatically closed minded in listening  to suggestions to to make macros productive with even little effort on their part.  Preferring to address only the suggestions of those who chose not to understand the technology. That's a very, very old management trick to derail a promising trend and protect the "old guard". I'll continue to help those that want help but do agree with most here that macros in Chief are 'generally' counterproductive as implemented now. But the trend is changing (BIM)-- just not at Chief.

[Joe_Carrick]

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.

[Joe_Carrick]

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.

[GerryT]

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.

 

You have to use an external line_style program or just use a text editor -- you CAN NOT use Chief's custom line_style editor as Chief will recognize similar line styles to avoid a name clash. However, you can create a identical line styles by just changing/duplicating the attributes. Then import into Chief.

 

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.

 

YES ,they are available and are listed as such as Demoed by my videos - try watching them. -- Fill -- pattern_angle.

 

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.

 

Never use layers as identifiers as it complicates the program. And my brain needs less complications now. What we really need is a readable name field , as you mentioned. Was taken out in X4 and a huge mistake.

 

Always open to a goto if not clear.

[Joe_Carrick]

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.

[Joe_Carrick]

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

[tchomes]

I just got back on here to see the responses and am amazed at everything I read and watched.  Huge shoutout to everyone who contributed on this thread.  I am all about efficiency and with my current workload, I'm trying to minimize the repetitive steps, like opening and copying the information from a window.  That is what I currently do.

 

I'll do some more reading on the Ruby tool.

 

Thank you!

Roy