More Macro Help!

[gteacher]

Joe:

You may want to look at using a combination of Hashes & Arrays. Unlike other languages, Ruby's hashes can store any object(s): other arrays, hashes, strings, numbers, etc (mix and match). The keys can be numbers or descriptive strings which makes it quite useful to organize and store data like this & you don't need to remember index numbers.

You may be aware but thought others interested should also be aware of the options? It's a matter of preference. BTW -- Chief is aware of the short comings mentioned. Just wondering if their paying attention to the actual users of their product?

[Joe Carrick]

Gerry,

I don't have to remember index numbers. I match the room name with the $DeckNames to get the index and then use that automatically to coordinate with the corresponding $DeckAreas data.

I could also use just a single array $Decks and store sub-arrays but that gets a little more difficult to code. I don't know if you were aware that Ruby Arrays can have mixed data types.

I should probably look at Hashes but since I've never used them before it would take a bit more study on my part. I suspect that my dual array method does pretty much the same thing as a Hash. Hashes would probably be more efficient but for what I'm doing it doesn't seem to make any difference.

[gteacher]

BTW ---

I like what you doing but you might want to take it a step further. In that, if you add or delete a porch, deck, bedroom, the analysis will automatically update without user intervention. Adding is easy, deletions require more programing because once added, globals remain in memory.

Consider adding a time stamp and automatically purging any deleted objects (not updated) so that your cals need only add up objects of a defined type for the area analysis. Hash keys set to nil or removed automatically purge that object.

[Joe Carrick]

BTW ---

I like what you doing but you might want to take it a step further. In that, if you add or delete a porch, deck, bedroom, the analysis will automatically update without user intervention. Adding is easy, deletions require more programing because once added, globals remain in memory.

Consider adding a time stamp and automatically purging any deleted objects (not updated) so that your calcs need only add up objects of a defined type for the area analysis. Hash keys set to nil or removed automatically purge that object.

You are absolutely correct about deletions. I currently use one of the following to update after deletions:

1. Execute a macro that resets all the globals to default values which causes the arrays to get rebuilt to only the remaining items.
2. Close Chief - Restart Chief - Open the Plan. Has essentially the same effect as #1.

In both instances I have to redisplay each floor.

Unfortunately I don't know any way to use a time-stamp at this point - other than just checking every time the array is scanned and if it's more than a minute or so since the last update - set the Area Data to 0 but if that room happens to be on a floor that I don't redisplay it could improperly eliminate valid data. IAE, it's something to think about.

[perryh]

The Room finish Schedule add and deletes rooms on the fly without any problems, depending if you check" include in Schedule" or not. Does it use macro's for that.

[Joe Carrick]

The Room finish Schedule add and deletes rooms on the fly without any problems, depending if you check" include in Schedule" or not. Does it use macro's for that.

Very true - but none of that is available to Ruby so we can't perform automatic calculations with it.

I'm also interested in creating a completely different Room Finish Schedule. I want it organized and formatted differently than what Chief provides. If I had access to all room attributes (Chief doesn't currently provide everything) I could create one to my own specs. OTOH, it will be interesting to see when X6 is released if Schedules have become more flexible.

[gteacher]

Perry:

Probably does somewhere. But I'm not talking about living area but automatic area analysis & auto breaking out of external vs internal, site, & by room type etc.

Joe:

My point that those steps aren't necessary -- unless that's the way your comfortable with.

Basically, instead of just storing a value for each object, you store a array containing a time stamp, & value(s) array. The value(s) array can be different for each type of object and contain several avail values stored automatically.

A purge macro runs with each cycle to look at the time stamp and if not up to date within(?) deletes that global. In this manner, the program only needs to add up objects of the same type ID using a enumerator. i.e the sum formula never need be changed.

The purge macro can be placed on each floor and use a global to identify floors -- ignore floors (globals) your not currently on.

I didn't go into details because I didn't know if you or anyone else was interested? If so I can supply example macros -- but more set up, so maybe a step too far?

[Joe Carrick]

Gerry,

I understand - I may follow that route. Obviously, I would need to create my own "Floor" global on each floor because Chief doesn't provide an attribute for that (same as for "page"). Even if an array or hash element was removed because of time, it would immediately be added back if the item was present.

Nice idea. Thanks.

[gteacher]

I understand - I may follow that route. Obviously, I would need to create my own "Floor" global on each floor because Chief doesn't provide an attribute for that (same as for "page"). Even if an array or hash element was removed because of time, it would immediately be added back if the item was present.

Nice idea. Thanks.

Yep -- Your welcome

[Joe Carrick]

Gerry,

If I create Hash Entries for Rooms like this:

$Areas[name] = {type, standard_area, Time.now, $Floor}

then:

$Areas["Deck #1"][0] => "Deck"
$Areas["Deck #1"][1] => 220
$Areas["Deck #1"][2] => 2013-10-07 15:17:33 -0800
$Areas["Deck #1"][3] => 1

Is this correct?

Can I access the data sequentially using an index number in a loop?

[Joe Carrick]

For me it'll be better to do as follows:

$RoomAreas = []
$RoomAreas[i] = [name, type, standard_area, Time.now, $Floor]

then:

$RoomAreas[i][0] => "Deck #1"
$RoomAreas[i][1] => "Deck"
$RoomAreas[i][2] => 220
$RoomAreas[i][3] => 2013-10-07 15:17:33 -0800
$RoomAreas[i][4] => 1
etc.

$RoomAreas can contain all room types and I can retrieve the areas based on type. Anytime the Array is scanned I can check the Floor and Time Stamp to see that it's current. If not I'll remove that item.

This will make the Array larger but it will eliminate having an array for each room type.

[gteacher]

Your completely correct -- but your thinking multi dim array rather than hash. the first part (dim) is the key value, so its more correct to think returned object, than next returned object, than next etc. -- same as stacked casts in c++;

i.e. ($area["Deck#1"])[3] -- assuming key's "Deck #1" return is a array (Could be another hash) Your code should work and usually does, but the interpreter in 1.9.1 sometimes gets confused without help -- Don't know why.

You can use a index but better to use a enumerator.

$area.each { |key,value|
value.each {|x|
x = some code
}
}

Also -- caps are usually reserved for constants and classes in Ruby

You initialize hashes by --- hash = {key => value, key => value ......}
or just -- hash["some key"] = "something"

or

arr = Array.new; arr.push("something"); arr.push("somemore") etc,
hash["mykey"] = arr

etc.
etc.
Be careful to create a new array rather than reusing a name because arrays & hashes are passed by reference and you may step on your code.

[gteacher]

Joe:

you can type faster than I can get back to the computer. I'll try to catch up in a bit

[gteacher]

Second Post:

Works just as well
But a technicality -- Note: Ruby does not support Multi dim arrays, but any array can contain a array -- same thing -- but better to use () to better identify & not confuse the interpreter (sometimes).
Also Ruby has no support for multi enums.
Need to cascade same.