On 05 Aug 2003 10:57:18 +0100, kcorey <[EMAIL PROTECTED]> wrote: > >On Tue, 2003-08-05 at 10:43, bullshark wrote: >> >2) Allocate an array from dynamic memory for the strings and copy all >> >the strings into memory. >> >> That's the ticket. 'Dynamic'. Copy is what you do when you draw. >> The difference is that with a LstSetListChoices you have access to the >> list after you create it. > >So you're saying that it's better to allocate n blocks of memory,
If you are referring to that abominable example in the article then the answer ia absolutely not. The author was on drugs. He/She didn't have a clue how to manage memory or Dynamic lists. If done correctly, the list is allocated/freed with one MemPtrNew/Free call. >I'd rather not clutter up dynamic memory with any more locked blocks >than I must. One locked block per list? Sheesh. But still I must ask "Why?". Locked-Schmocked...Locked memory is nothing. The principle purpose of Handles is to permit reorganization of DB memory into contiguous extents for sequential access. For purposes of lifetime program allocations, it is inconsequential. > >> No, you're not chewing up 'large amounts' of memory, and what is the >> memory for anyway? Do you think your program is 'better' if it leaves >> the heap unutilized'? > >It's quite simple: you're less likely to run out of memory if you're >careful of your memory requirements. Less likely than what? I've never run out. That would be 'Less likely than Zero'. Code space OTOH, is in desperately short supply. >Until your program is done, you're never sure exactly how much memory it will require. Why is that? If you're talking about "to the byte" your life must be hard. Knowing requirements to the nearest 10K is good enough and quite easy to estimate. >Why burn memory when you don't need to? There's not enough dynamic >memory on the Palm as it is. There's not? What are you doing with it? Burning it up with C++? If that's the case, then we're on different pages. > >> So is LstSetListChoices. Quite a bit easier, in fact. > >You're not taking into account allocation/assigning >strings/deallocation. Yes I am. Deallocating is: if(pListTxt != NULL) //pretty hard memPtrFree(pListText); //huh? and there are at most two of those clauses for a dynamic list. Since one of those is in the builder method, it is never repeated for additional lists. Additional lists get one clause in the stop program method. >> Not as boiler plate as LstSetListChoices(). Your code is a maintenance >> chore. Building a list for LstSetListChoices is a piece of cake. >> It is so 'boiler-plate' that a single subroutine, written once, lib'd >> and never touched again will do for most applications. > >*smile* I'm glad you've found a solution that works for you. I didn't find it. The solution was provided by the engineers that developed the API. They even provided support methods to make the job easy. The API is one of the most efficient and finely crafted in the world. If you use it well, as intended, very small programs do very large things. All I do is make use of it, as opposed to replacing it. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
