ItemData, ItemIdData
These two array properties
let you associate a number with each item in a list or combo box.
Usage
|
oObject.ItemData( nIndex ) = nValue
nValue = oObject.ItemData( nIndex )
oObject.ItemIdData( nItemId ) = nValue
nValue = oObject.ItemIdData( nItemId )
|
There are two properties here where it seems one would
do. Like List and ListItem, these are really just two names for
the same array. The difference is in how you access them.
ItemData keeps things in order by the item's Index, while
ItemIdData is ordered by the item's unique ItemId. (See AddItem
for an explanation of Index vs. ItemId.) What does this
dual-named array actually hold? By default, nothing. The elements
get created as the list items are added, but there's nothing
there. You get to fill them up.The docs say that these properties
only work right up to 60 items. They're partly right. In VFP 3,
there were a number of problems with lists containing more than
60 items, but those got fixed in VFP 5. Of course, that's the
version where the limit was first documented. Oops. We've tested
with lists containing up to 10,000 items (despite our feeling
that that's at least 9,000 more items than we think should be in
any list box), and ItemData and ItemIdData had no problem keeping
up.At first glance, we thought these would be pretty cool. We
could imagine sticking, say, employee names in the list and
putting their IDs in ItemData/ItemIdData. But you can only put
numbers in these, not other types. While that works if you're
using Integers for surrogate IDs, you can also just put the IDs
into the list and not show them. And, in fact, if your list is
based on an array or a table, all the data is available through
the List and ListItem collections anyway. We have come up with
one case where ItemData/ItemIdData seems useful. Suppose you have
an array or table and you want to put some (but not all) of the
items in a list. You can use AddItem or AddListItem to put the
items you want in the list and then use this array to hold the
row number in the original array or the record number (or primary
key) of the item. Then, when the user picks an item, you can look
up the row or record number and get right back to the original
data.Of course, there are other ways to handle this situation,
but we'll never turn down a gift horse. Bottom line—we have yet
to use these properties, other than for testing.
Example
|
* Fill a list with only those Employees that have a
* sales region listed. Set up ItemData to hold the
* recno() for each such employee.
SELECT Employee
SCAN
IF NOT EMPTY(Sales_region)
This.AddItem(Last_Name)
This.ItemData[ This.NewIndex ] = RECNO()
ENDIF
ENDSCAN
|
Back to Table of Contents
Copyright © 2002-2018 by Tamar E. Granor,
Ted Roche, Doug Hennig, and Della Martin. Click for license
.