KPURCELL@LIVERPOOL.AC.UK (07/27/90)
I am posting this for Mahboud Zabetian <AG.GROUP@com.apple.applelink>. Please direct replies or comments to him. ^Kevin ^Purcell .........................Comments? Questions? Flames? Applause? \ Surface Science \ Waiter,Waiter, \ Liverpool University \ There's a bug in my soup....... \ Liverpool L69 3BX \ ....No Sir! Thats not a bug it's a feature... -------------------------- summarry follows ----------------------------- Hello. Here's the summary I promised. If one of you can post this to comp.sys.mac.programmer, let me know. I will be very grateful--my access to that newsgroup is limited. Let me refresh your memories. I was inquiring about the new *cool* List Mgr someone at Univ. of Miami had written. Well I got it. It is available via anonymous ftp from umbio.miami.edu, aka 129.171.65.204. And its author is Jack Herrington from the Univ. of Miami, School of Medicine. What I really wanted is a list manager that has the ability to have over hundred thousand entries. You might think I am crazy, but one of our products is an ethernet packet capture and analysis program that, on many networks, can capture over a hundred packets a second (6000 a minute) and we can't just drop the packets because the List Mgr can not handle them. (The most I could ever tweak out of the List Manager is about 16250 x 1 cells) Well the List Mgr on umbio is slow, uses too much memory and is really intended for a 100*100 grid (you can flag it to use one TE record per cell!!!!!) For what it does, it is great, but we need something different. So we have been writing our own, and my recommendation to you is to do the same. It really is not that hard to do. The part we are stuck at right now is the ListClick routine, but that should be done soon. At this time, our list can handle 64K x 1 cells. It would be able to handle more (i.e it won't crash or do the wierd things that the LMgr does -- until you reach sizeof(signed long) where it will stop accepting LAddRows), but the limiting factor is the scroll bars. Scroll bars have a range of -32768 to +32767 (unless you define your own CDEF -- maybe). My advice to you is: Use the list mgr chapter as a guide. Mimic their calls, as the interface is pretty reasonable, and you can compare your routines with the standards. Do not do the whole list mgr all over. Only implement the calls that you think you will need(you can always put them in later). Do not use the Jack Herrington's LMgr as a template. It is great to look at, but you can get away with using a lot less memory and more speed if you customize to your own needs. Don't f*&% around with a DataHandle and cellArray. Let your LDEF and program handle that. For example use the cell.v value that the LDEF gets called with to index into your own array of values that you want to list. And don't turn high bits on and off to signal selection, the way the listmanager does now. Maybe you could store selection state with your array, or you can have an array of bits (u_short select:1;) at the end of you ListRec. Our List Mgr, with using about 20 lines of assembly, is faster than the original, when you scroll, add, or delete, even with drawing on. And the sizeof the ListRec is eight bytes greater than the original(we don't use DataHandles and cellArray fields). The increase in speed is due to the fact that the List Manager calls its own routines, and does so by using the _PACK0 trap!!! That trap checks to see if 'PACK' ID=0 is loaded, then locks it, then goes through a jump table.... Anyway, if any of you need pointers, let me know. Or even handles. (sorry) Good luck. -mahboud