rubin@cis.ohio-state.edu (daniel j rubin) (06/25/91)
I want to write a application that will display all the items in a file on the hard drive using the list manager ( I think ). The database can have 10000+ records containing about 1000 bytes each which includes a name. I want to create a list of 10000+ names so when someone selects one of the names in the list the rest of the information will pop up. The problem I am having is I am not super familiar with the list manager. I read that you cannot create a list with more than 32K of data. How can I get around this or is there a better way to accomplish this using something other than the list manager. Thanks in Advance - Dan Rubin
rmh@apple.com (Rick Holzgrafe) (06/28/91)
In article <1991Jun24.231936.15327@cis.ohio-state.edu> rubin@cis.ohio-state.edu (daniel j rubin) writes: > I want to write a application that will display all the items in a file on > the hard drive using the list manager ( I think ). The database can have > 10000+ records [...] I read that you cannot > create a list with more than 32K of data. True enough, but you don't have to keep all the data in the List Manager's records. By writing a custom LDEF (very easy to do), you can simply keep pointers (or handles, or array indexes, or whatever) in the list, and have your LDEF use the pointers to access and display the real data kept elsewhere. Nevertheless, 10000+ records is really pushing the limits of the List Manager. You could do it if the list contained (say) 16-bit array indexes, but I bet it'll be slow. The List Manager was designed as a simple, standard way to present simple, reasonably small lists; it wasn't intended to be the perfect front end for a major database engine. What the List Manager does isn't that complicated. Consider writing your own solution, tailored to your needs. (And while you're at it, give a little thought to different interfaces altogether. Obviously I don't know the details of your needs, but I for one wouldn't enjoy scrolling through 10000+ records, trying to find the one I want...) Hope this helps. ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."
omh@cs.brown.edu (Owen M. Hartnett) (06/29/91)
In article <14272@goofy.Apple.COM> rmh@apple.com (Rick Holzgrafe) writes: >In article <1991Jun24.231936.15327@cis.ohio-state.edu> >rubin@cis.ohio-state.edu (daniel j rubin) writes: >> I want to write a application that will display all the items in a file >on >> the hard drive using the list manager ( I think ). The database can >have >> 10000+ records [...] I read that you cannot >> create a list with more than 32K of data. > >True enough, but you don't have to keep all the data in the List Manager's >records. By writing a custom LDEF (very easy to do), you can simply keep >pointers (or handles, or array indexes, or whatever) in the list, and have >your LDEF use the pointers to access and display the real data kept >elsewhere. > No, No, Don't put anything in the List Manager's data, that's the key! Your LDEF gets the number of the cell it needs, you use that number to index into your own data and draw it into the rect that the LDEF also gets. >Nevertheless, 10000+ records is really pushing the limits of the List >Manager. You could do it if the list contained (say) 16-bit array indexes, >but I bet it'll be slow. The List Manager was designed as a simple, >standard way to present simple, reasonably small lists; it wasn't intended >to be the perfect front end for a major database engine. > 10,000 records isn't bad, I've done it with >18,000 records with no problems and response was indistinguishable from a 50 record list. Keep your data out of the List manager, and just use the List Manager routines to manage the interface. >What the List Manager does isn't that complicated. Consider writing your >own solution, tailored to your needs. (And while you're at it, give a >little thought to different interfaces altogether. Obviously I don't know >the details of your needs, but I for one wouldn't enjoy scrolling through >10000+ records, trying to find the one I want...) > You don't have to roll your own, if you do what I've said. Practically speaking, you'll also need an additional way to display desired records, such as typing the beginning of the search key and have it scroll to the first match found. Please no flames on a 10000 record scrolling list. I've researched it pretty well and have determined that it was the most workable way and the implementation actually works better than you would think. -Owen Owen Hartnett omh@cs.brown.edu "FAITH, n. Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." -Ambrose Bierce - The Devil's Dictionary