On Tue, 5 Aug 2003 19:42:13 -0700 (PDT), James <[EMAIL PROTECTED]> wrote: >Alan Ingleby wrote: >> Besides, if you want incremental search, your list is probably going to >> be pretty huge, so trying to manage it with ListSetListChoices is going >> to be nasty.
How is that? The beauty of a loop is that it's complexity is not affected by scale. 10 or 1000, the code doesn't change. >Exactly my point; for huge lists, you often don't want to use LstSetListChoices >because you're retrieving the strings from somewhere else, Well, you've hit on a problem. Permanent vs transient. In a very few cases, the choices will exist as text naturally. In most cases for lists, the text is generated from much smaller fields. Should the designer choose to store the list text in the DB records *For the list's sake*, then memory is permanently consumed. That is a far more serious problem as far as users go. Using the heap (transient) to form the text strings is friendlier to other applications and purposes. Dynamic memory use is an instance problem for the programmer to solve. Permanent memory is a headache for the user. >and you don't want to deal with the extra memory requirements and management. I think too much is made of this. A list of 500 items with an average width of 10 characters consumes 7500 bytes. Is this a big deal? It amounts to .3% of the memory available on a lowly PIII or Zira. Yes, it's true that a palm chock-full other programs and records brings the ceiling down lower and lower, but (for large applications) this is irrelevant. I have no qualms whatsoever instructing my user that they need 'X' amount of free space to run my application. Whether they delete Minesweeper, or cleanout their memos, I don't care. When 7500 bytes is a critical issue, they can't do anything useful with my applications anyway. 500 is just a number plucked from the air, but it strikes me as too large. I would think long and hard about alternatives before burdening the user with something like that on purpose. This is a small platform for small applications. You can write large applications successfully, but to make a user happy with the result, considerable thought needs to be given to the API and the way it is intended to be used. The source code for the standard applets are testaments to "the way". When a Custom DrawList is called for (with it's attendant execution for *each* item in the list), how much easier/faster is it to simply fetch the text from your own store which is already built? The API is SO FOCUSED on the EXPECTATION that it supplies the list to your drawList function. How much more hint do you need? >Hence, the system >/ought/ to be able to accept a callback so that it can retrieve the text to a >list item whenever it needs to. That's a thought, but is it realistic? A search that has no control over the content of the list to search has no control over the order, and no ability to search effectively. The callback would not even be able to guarantee a constant set for the search in progress. Each character addition would force a fetch of all text through the callback...It would probably violate the 'instant/interruptable' edicts right off the bat. The problems are manifold. The code is already there. The API already does what you want. Applications that use LstSeListChoices() use it freely, because it costs nothing. I've been writing for the palm for several years. I don't know when or where this trend to use DrawList came from...I suspect it's attractive to the novice C-Crowd that has a difficult time with pointers and dynamic memory in general. For them, the construct is not just intimidating, it's downright mysterious. Add to that the sinister spectre of Handles/Chunks/Locks and any amount of pastable solution that avoids their use is acceptable as an alternative. I remain steadfast in my conviction that LstSetListChoices should be used in all but the most trivial cases. The best Palm apps look, feel and run like the standards and the best way to get there, with the smallest amount of code is to use the API the way it's designers intended. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
