Lynch, Jonathan wrote:
I have a table object that consists of fields which serve as cells,
inside of groups which serve as rows, inside of a group which is the
table.
Each Row is named group mRow_1, mRow_2, mRow_3 etc...
When you drag a row so that it is moved in between two other rows, its
name is changed. Each row holds a customproperty describing the location
of information in another stack.
When you type in the other stack, the change is reflected instantly in
the table. To do this, it goes to the table in question, and looks for
the row containing the appropriate custom property, than changes the
text in that row.
It works great, and I cannot see any slowness. However, if I had a
couple hundred rows, I think there would be some slowness with having to
search for the appropriate row on every single keystroke.
See, I cannot tell it to make a change to the row by its name without
first searching for the row that contains that name, because its name
may change as rows are added, deleted, or moved.
I could do it by its altid property - but I don't trust altID - it makes
me nervous because it is addressed through the same commands as the ID
property. If it was addressed like this: Field altID 100 - well, that
would work fine. But as it is set up right now, it can get confused
between field id 100 and field altid 100.
I think altID is the way to go because it also lets you reference things
numerically, which seems well suited to what you're doing.
I was playing with the altID last week and got over my own trepidation
about it. My big question was how the lookup happens, whether the
engine searches both IDs of each object or searches ID for all and then
altID for all -- turns out it's the former.
For example:
1. Make two buttons
2. Set the altID of the first button to the ID of the second
(let's assume that second ID is "1002")
3. Run this in the Message Box:
select btn id 1002
Result: the first button is selected
At first this sounds like a recipe for disaster, but there are only two
things to keep in mind to use it effectively:
a) Each stack has a single ID incrementer for all objects, and
it starts at a very low number (1001?)
b) Valid ID numbers go up to 2 billion
So if you establish a base ID well above a million you should never
conflict with the engine's ID numbering scheme (unless of course you
have more than a million objects, but then you'll have other problems to
deal with <g>).
This means once you've set the altIDs you can do something like this:
put 1000000 into tBaseID
repeat with i = 1 to 100
get the whateverProperty of fld ID (tBaseID+i)
end repeat
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
