altID

[Richard Gaskin]

Though I've rarely used altIDs, when I did some testing on this a while 
back I found that they could be used in just about any syntax in which 
the ID could be used, e.g.:

    get the loc of btn id tMyAltID of grp id tMyTrueID

IIRC from those tests, the engine does the lookup in object order, 
checking first the true ID and if no match is found then it looks for a 
match on the altID.

This means of course that you could potentially have a conflict if you 
try to use an altID in the range of true IDs in use.

The range of numbers for altIDs goes up to 65535, and if you start with
a number well above the number of objects in your stack plus a few
thousand you should never have a conflict.

Built-in IDs start at 1001 and all objects are apparently incremented
from the same counter, so a new card will be 1002, a button added there
will be 1003, etc.

So if you know the sum of all objects will be fewer than 9000 (that
would be a hefty project), you could safely start your altIDs at 10000, 
giving you a range of more than 55,000 custom IDs.

BZ#3089 is a request to extend the range of altIDs to match the limits 
of true IDs - you can add your votes to it here:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=3089>

Thanks to Dick Kriesel for bringing that to my attention.


I agree with the assessment that there's much that could be done to make 
it easier to create and manage custom controls in Rev.  For example, if 
we had some sort of locked property for groups we could select them as 
if they were a single object, regardless of the current state of the 
selectGroupedControls global property:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=2144>

But while it could be easier, I haven't seen anything yet which makes 
such gadgets prohibitively difficult in Rev today.

As one example I have a table object I use in a number of apps, and a 
couple other developers have used it in their work as well. (If my 
client work ever slows down enough I hope to get around to packaging 
that for public consumption).  I don't bother with IDs at all there, 
custom or otherwise.

Each grouped table object only contains the barest code needed to call 
handlers in a shared library.  Table settings (header names, column 
widths, list contents, etc.) are all set through custom properties, and 
the library contains getProp and setProp handlers to drive the behavior 
in the target object.  This minimizes replicated code, and allows me to 
make changes to just one library to address bugs and extend behaviors 
across all instances in any project.

By using properties to drive the control, the getProp and setProp 
handlers just refer to "the target" to find the object being acted on, 
so there's no need to hard-wire IDs anywhere in the scripts.

This property-driven method also feels more or less "natural", given 
that most of the basic appearances and behaviors in Rev's own native 
controls are driven by properties.

I'm sure there are cases where writing hard-wired IDs in scripts could 
be useful, but I can't say I've ever needed to do so in my own work.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com