domenikos@emass1.enet.dec.com (George Domenikos.) (04/24/91)
Hi there, I am have encountered the 32K limitation on the list manager storage capabilities. I have a list in which I would like to store at least 1000 entries of about 160 bytes per entry. However my list runs out of space at about 250 entries or so ( 32K) and all the offsets of my entries get out of alignment and eventually my data becomes junk. Is there any commercial or other wise library of routines to imitate the list manager calls. I am looking for something to link to my application to overcome the 32K limitation of the sort BreakBarrierLNew, BreakBarrierLSet calls etc... If nothing like that is available out there I would like at least to have a similar high level LDEF along with each make file that deals with the problem. Thanks in advance George
jeremyr@cs.qmw.ac.uk (Jeremy Roussak) (04/26/91)
In <4501@ryn.mro4.dec.com> domenikos@emass1.enet.dec.com (George Domenikos.) writes: >I am have encountered the 32K limitation on the list manager storage >capabilities. I have a list in which I would like to store at least 1000 >entries of about 160 bytes per entry. However my list runs out of space >at about 250 entries or so ( 32K) and all the offsets of my entries get >out of alignment and eventually my data becomes junk. One easy way round this is to store pointers (or better yet, handles) to your data in the list. You can then have >100,000 items in your list with no problems. Building the list will be much quicker, too. You'll have to write an LDEF to draw the items in the list, but LDEFs are terribly simple to write. Jeremy Roussak
neeri@iis.ethz.ch (Matthias Ulrich Neeracher) (04/26/91)
In article <3604@sequent.cs.qmw.ac.uk>, jeremyr@cs.qmw.ac.uk (Jeremy Roussak) writes: >In <4501@ryn.mro4.dec.com> domenikos@emass1.enet.dec.com (George Domenikos.) writes: >One easy way round this is to store pointers (or better yet, >handles) to your data in the list. You can then have >100,000 ^^^^^^^ >items in your list with no problems. a) how do you address the 100'000 items ?? Cells have only a signed 16-bit vertical component (limiting the items to 32767). b) I find it easier *not* to store *any* data in the list, but use the Cell parameter to the LDEF as an index into my own data structure. If you store a pointer for each item in the list, you are limited to 8191 items. >Building the list will be >much quicker, too. Relatively spoken, yes. > You'll have to write an LDEF to draw the >items in the list, but LDEFs are terribly simple to write. "Simply terrible" is another word for it :-) >Jeremy Roussak Matthias -- Matthias Neeracher neeri@iis.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
mxmora@unix.SRI.COM (Matt Mora) (04/26/91)
In article <3604@sequent.cs.qmw.ac.uk> jeremyr@cs.qmw.ac.uk (Jeremy Roussak) writes: > >One easy way round this is to store pointers (or better yet, >handles) to your data in the list. You can then have >100,000 >items in your list with no problems. Building the list will be >much quicker, too. You'll have to write an LDEF to draw the >items in the list, but LDEFs are terribly simple to write. Jeremy, I would like to see how you get the list manager to deal with > 100,000 items with no problems. I see a limit of 8192 by storing ptrs or handles in the list. 16384 if you get really tricky. Matt -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
jeremyr@cs.qmw.ac.uk (Jeremy Roussak) (04/29/91)
In <23645@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: >>One easy way round this is to store pointers (or better yet, >>handles) to your data in the list. You can then have >100,000 >>items in your list with no problems. >I would like to see how you get the list manager to deal with > > 100,000 items with no problems. I see a limit of 8192 by storing ptrs >or handles in the list. 16384 if you get really tricky. >Matt I apologize for the (temporary) brain and arithmetic failure. It was (or seemed) very late... Jeremy >-- >___________________________________________________________ >Matthew Mora | my Mac Matt_Mora@sri.com >SRI International | my unix mxmora@unix.sri.com >___________________________________________________________
oster@well.sf.ca.us (David Phillip Oster) (04/29/91)
One easy way to get around the 32k limitation on data stored in a ListHandle
is: Don't store the data in the list handle. An LDEF gets called with the
coordinates of the cell to draw, so it can use those coordinates to look up
the data some where else.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- oster@well.sf.ca.us = {backbone}!well!ostertime@ice.com (Tim Endres) (04/29/91)
In article <3615@sequent.cs.qmw.ac.uk>, jeremyr@cs.qmw.ac.uk (Jeremy Roussak) writes: > >>One easy way round this is to store pointers (or better yet, > >>handles) to your data in the list. You can then have >100,000 > >>items in your list with no problems. > > >I would like to see how you get the list manager to deal with > > > 100,000 items with no problems. I see a limit of 8192 by storing ptrs > >or handles in the list. 16384 if you get really tricky. > > >Matt > I apologize for the (temporary) brain and arithmetic failure. > It was (or seemed) very late... There was a List Manager replacement posted here a year or two ago with complete sources. That would be a good place to start a project for the "immense" List Manager. As people pointed out, the Apple List Manager has some hard limits. tim. ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
grendel@aix01.aix.rpi.edu (Thomas E DeWeese) (04/30/91)
In article <1CE00001.edjyz6@tbomb.ice.com> time@ice.com writes: > >> >I would like to see how you get the list manager to deal with >> > > 100,000 items with no problems. I see a limit of 8192 by storing ptrs >> >or handles in the list. 16384 if you get really tricky. >for the "immense" List Manager. As people pointed out, the Apple List >Manager has some hard limits. > >tim. I would be very interested in how you expect someone to navigate through a list that has >100,000 items. I really strikes me that you should rethink this use of the list manager. Make it Hierarchical like the SFdialog. Other wise it would take >1000 clicks in the scroll bar (moving a page assuming 100 elements on screen at once). or an accuracy of about 200 elements (two screens) by dragging the scroll bar thumb (this is down to the pixel). I would think that this would be very unusable. grendel@rpi.edu Thomas DeWeese
slang@bmerh563.bnr.ca (Steven Langlois) (04/30/91)
In article <1CE00001.edjyz6@tbomb.ice.com> time@ice.com writes: > >There was a List Manager replacement posted here a year or two ago >with complete sources. That would be a good place to start a project >for the "immense" List Manager. As people pointed out, the Apple List >Manager has some hard limits. > Anyone have any idea where the List Manager replacement is? I looked on sumex and could not locate it. Steven Langlois ISDN Basic Rate Access BNR, a subsidiary of Northern Telecom Bitnet: slang@bnr.ca Bitnet from AppleLink: slang@bnr.ca@DASNET#
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (05/02/91)
Tim Endres writes in a message to All > > > 100,000 items with no problems. I see a limit of 8192 by storing ptrs > >or handles in the list. 16384 if you get really tricky. > > >Matt > I apologize for the (temporary) brain and arithmetic failure. > It was (or seemed) very late... TE> There was a List Manager replacement posted here a year or two TE> ago with complete sources. That would be a good place to start TE> a project for the "immense" List Manager. As people pointed out, TE> the Apple List Manager has some hard limits. Someone mentioned a "virtual list" awhile back that uses the List Manager for display only and keeps track an unlimited number of entries elsewhere, dumping them into the List Manager as scrolling requires... Lawson -- Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English Internet: Lawson.English@p88.f15.n300.z1.fidonet.org
Invader@cup.portal.com (Michael K Donegan) (05/07/91)
Does anyone ever think of the user? What kind of a silly user interface do you present if you put more than a very small number of items in a listbox. A list that must be scrolled is ridiculous unless 1) you don't need to use it very often 2) you are intimately familiar with its contents so that you can use keystrokes to get you in the vicinity of your search. I am particularly sensitive to this because if have been working on a program with over 200 source files. I have gotten really sick of using the Open Dialog to find the one I'm looking for and use the Finder instead. At least the finder lets you organize the files anyway you want and uses color cues (maybe the colors should be reflected in the open file dialog?) Also, there should be a user preferences for the speed of typing at a listbox. I'm a pretty fast typist, but I often wish that I could type at a listbox with one hand and still have it work. You have to use both hands to be able to type fast enough if the files are not unique until the third character (as ours are.) Anyway, find a better user interface rather than burden the list manager. Just because it is easy to program doesn't mean you should use it for everything. One man's opinion, mkd
omh@cs.brown.edu (Owen M. Hartnett) (05/08/91)
In article <42087@cup.portal.com> Invader@cup.portal.com (Michael K Donegan) writes: >Does anyone ever think of the user? What kind of a silly user interface >do you present if you put more than a very small number of items in a >listbox. A list that must be scrolled is ridiculous unless 1) you don't >need to use it very often 2) you are intimately familiar with its >contents so that you can use keystrokes to get you in the vicinity of >your search. > >I am particularly sensitive to this because if have been working on a >program with over 200 source files. I have gotten really sick of using >the Open Dialog to find the one I'm looking for and use the Finder >instead. > >Anyway, find a better user interface rather than burden the list manager. >Just because it is easy to program doesn't mean you should use it for >everything. > > One man's opinion, > mkd Well, consider the following application: A real estate database accesses information via a map and lot number and the owner's name. There are thousands of records in this database. Sometimes the map and lot numbers are non-uniform (i.e. lot 1, lot 1.1, lot 2, lot 3, etc). Either you display a range of lot numbers as in the list manager or you require the user to remember the lot number and type it in. Unless you have a better idea? BTW, the list manager will handle the "burden" quite nicely (I've done it with over 20,000 records) Scrolling isn't that great but when you're dealing with that many records you can use other methods to get near the record you want and then scroll to "fine tune" till you find your record. -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