Ruby calculation of Current Floor

[Joe Carrick]

Since CA hasn't given us a Ruby Attribute for "Current Floor Number", I've devised a way that works for most cases.

Current_Floor = ((floor_elevation+120)/120).round(0)

This can be placed in any macro that has a Room as the Owner (Room Label works). It's based on the idea that the floor height is in the range of 6'-14' and that the First Floor is at elevation 0.00

[dshall]

Very clever Joe.

[Joe Carrick]

Now if I could just figure out a way to get "Current Layout Page". Unfortunately there's nothing similar to floor_elevation to use as a base for the calculation in the Layout.

[dshall]

Since CA hasn't given us a Ruby Attribute for "Current Floor Number", I've devised a way that works for most cases.

Current_Floor = ((floor_elevation+120)/120).round(0)

This can be placed in any macro that has a Room as the Owner (Room Label works). It's based on the idea that the floor height is in the range of 6'-14' and that the First Floor is at elevation 0.00

You know that when I first read this my first thought was JC was being kookier than me. But as I was just taking a shower thinking about this, I have a use for this macro right now.

Between JC's nutty ideas and Perry's "I hate to type" macros, there is a lot of potential here. CA should start to seriously get into the macro business. Thanks JC, hey JC, you want to play golf this Thursday at the RBI at 1:30 with Bruce, The Mailman and myself? I already have a tee time, and yes, drinks are on me after the round.

[gteacher]

CA should start to seriously get into the macro business[/B].

Don't think that will happen now. But I can tell you that with one or two tweaks; we could make Chief a industry leader. The frustrating part is that Chief doesn't seem to want to go there. ( Chief --- correct me if I have the wrong impression. The necessary tweaks are very minor -- soooo something else must be going on?).

Joe:

Don't see why your going to all the trouble - I just use a hidden macro on each floor: $floor = 1, etc. Works fine for cals, summaries, purges, layout etc.

Works fine for layout pages too, if you want to put a hidden macro on each page of your layout template --- messy

[Joe Carrick]

Joe:

Don't see why your going to all the trouble - I just use a hidden macro on each floor: $floor = 1, etc. Works fine for cals, summaries, purges, layout etc.

Gerry,

I can't depend on the order of macro execution. Putting the calc in the macro that needs the floor number insures that it's current and correct.

[gteacher]

I can't depend on the order of macro execution.

That's True, But since the macros update with every screen update. A single mouse spin will execute the macro sequence a couple of time and go through all macro which usually straighten things out -- fine from there on. Just have renumber to do a update when you move to a new floor. Things work fine after that.

Worst problem is when you have to trouble shoot through the macro management DBX. Things got out of sequence and do not always reflect properly -- Have to keep jumping out and in. So many limitations, still not sure this is useful to the average user?

[spencerdesign]

Now if I could just figure out a way to get "Current Layout Page".

%page% an layout page 0. Or did you mean something else?

[mkennedy]

Seems to me that macros are generally less than desirable for core function. I don't believe there's a long history of industry success stories of software that requires users to write macros prevailing over software that does stuff OOB.
I'm thinking that labeling details, compiling schedules, tabulating finishes, ought to be automatic OOB with some room for adjustment. I hate making a sheet index for every job - and many jurisdictions require one, so it's not a personal preference, its a standard of the community. As such, a program that represents itself as being able to produce construction docs ought to be able to produce a sheet index.
There's a whole list of schedule and label issues in Chief, frustrating to know the data is there, the program could access\present the data, it just chooses not to.
As an occasional user, just a couple hours a day, it's hard to justify investing say 80 hour\year (2 hours \work day, 1 day per week of use) to save say 30 minutes per job, 20 jobs\year=10 hours return on my 80 hour investment. So I continue to manually build a sheet index, wrestle with goofy schedules, label details and sections that should be labeling themselves and resent CA all the while. Sometimes I get so resentful, or invest so much time fine tuning stuff that I have to skip an upgrade to recover my investment of time over 2 or 3 years.
FWIW, CA is already a tough program to use as an office standard. I have tried hiring drafters and found the the degree of idiosyncracy is huge. Work produced by one drafter is so different than work produced by another - where are CAD details, are details live, how do they use annosets. I didn't have these issue hiring drafters using OtherCAD. There is a plentiful supply of trained\experienced drafters and standards seem easier to implement. In fairness, this may be due to my trying to use freelance drafters instead of hourly staff and obviously 2d is simpler than 3d, but it's surely frustrating to deal with and might be assuaged by CA having really robust processes and tools for the production of documents.

[Joe Carrick]

%page% an layout page 0. Or did you mean something else?

I mean the actual number, not just a text display. %page% can't be used in another macro to get a number - it just displays the result as text.

I need to have the numerical value to use as an index into an array of text strings.

[Joe Carrick]

Perhaps I should explain further how I need to use the actual layout page number.

I have a macro that reads a simple text file containing sheet ID's and Titles - my sheet index for the project. This text file is in the Plan Folder for each project so I can modify it at will for each project.

G-1 TITLE SHEET
G-2 GENERAL NOTES
A-1 FIRST FLOOR PLAN
A-2 SECOND FLOOR PLAN
....
....
....

The macro places the text into a set of Ruby Global Arrays:

$Sheet_ID = ["0", "G-1", "G-2", "A-1", "A-2", .............]
$Sheet_Title = ["BLANK", "TITLE SHEET", "GENERAL NOTES", "FIRST FLOOR PLAN", "SECOND FLOOR PLAN", ........]

I have a macro on page 0 containing the following:

$Sheet_ID[$Current_Layout_Page]

Then, if the the Current Layout Page = 2 that macro returns

"G-2"

I have another macro on page 0 that displays the entire index. When I change the text file the Sheet Index and the Sheet_IDs get updated automatically.

All of the above is set up automatically in my Default Layout.

The problem currently is that $Current_Layout_Page simply isn't available. %page% doesn't work for this purpose.

What I'm trying to do is to automate a lot of what CA has left out of the box. Ruby can help do that but only if the needed attributes are available. Currently the Sheet Index works fine because it doesn't need to know what page it is on. But Sheet_ID needs a page number so I have to put a text box on each page with the correct number in a unique macro for that page $Sheet_ID[1], $Sheet_ID[2], $Sheet_ID[3], $Sheet_ID[4], etc. That makes it much more difficult to add/move/delete sheets.

There are some users that have the ability to do this type of programming. While it might not be cost effective for every user to learn Ruby and do the setup - it would be cost effective to have one of us do it for them.

[gteacher]

To be Clear(er)

You can achieve this by:

Putting a macro(s) on your layout template sheets. One macro on each sheet in a text box somewhere on that sheet, returning nil. Text box will be invisible.

example sheet one:

$layout = 1
nil

example -- sheet two:

$layout = 2
nil

etc. etc. --- twenty sheets -- twenty macros in your macro DBX.

On Sheet 0 - in the title block:-- use this macro

"#{$Sheet_ID[$layout] - #{$Sheet_Title[$layout]"

Problem is that your now have 21 macros in the layout template plus your ID macro(s). Maybe acceptable to some but not to most. If the macros could be hidden or put in a separate folder - maybe acceptable - but you can't. My point that the present limitations are just not acceptable and that Chief is just not listening. (or -- doesn't want to). Sooo - for the average user -- beware!!!!

[Joe Carrick]

Gerry,

I guess we're saying the same thing. If CA would provide a Ruby Attribute current_layout_page we would only need 1 macro on page 0.

[gteacher]

Gerry,

I guess we're saying the same thing. If CA would provide a Ruby Attribute current_layout_page we would only need 1 macro on page 0.

Exactly - Seems like a small bone to throw and would certainly be seen as a "act of good faith"