Bullshark, >why haven't I ever run out of heap? *Ever*?
In part because you (correctly) don't use lists for things with a large number of elements. I don't either; I'd typically use a table with lookup in that scenario. >I hardly ever write an application that uses static lists other >than category names... Static lists are not a problem anyway. The list resides in the resource which is in the storage heap. But you are right that they aren't useful all that often to begin with. >...and once again, why not use *all* the heap? Because I like to not run close to the wire. You never know how many hacks someone may have loaded. The more you use the more often garbage collection may have to be invoked to get the space requested. And quite frankly, because it seems to me (marginally) easier to use drawlist anyway. Not that the memory allocation method is overly hard, just unnecessary. >Have you ever run out? Yes, but never because of list objects or popups. >> char *src=GetAListItem(i); //this is simplified for brevity >Did you notice the comment on the line? The point was that it is >not complicated to create a list...whatever GetAlistItem represents, >it is required in either implementation, isn't it? Correct. In the case of drawlist, all that is required beyond that is to simply draw the result at the coordinates passed to the callback. >Work once >done that is preserved by LstSetListChoices for future reference I have yet to see a case -- other than incremental search -- where that mattered. It takes little enough time to re-fetch a given item (in lieu of LstGetSelectionText) or a set of visible rows (for scrolling) that it is a non-issue for me. >by LstGetSelectionText() (the cause of this thread) or for >incremental search. The cause of this thread was why LstGetSelectionText() can't be used with lists done via draw callbacks. To me that is a non-issue. You just call the routine analagous to your GetAListItem() instead of LstGetSelectionText. >Until you want to retrieve the text by index, That is what the GetAListITem() does anyway. >or you want to enable speed search. I've never had the need for this, and I don't think most users expect it as a norm in Palm OS based applications. Especially since it doesn't work in regular lists anyway, only popups. I use a table with lookup when I want a speed search. I trade the ability to use incremental searches in popups with the abililty to use fonts, coloring, alternate row shading, icons, etc when desirable, or mimic multiple columns in a list easily. Do I use these regularly? No, but certainly more often than incremental search. >>The callback just invokes GetAListItem() then draws >>it at the coordinates passed to the callback. > >Well, thanks. The point is that whatever *it* is, it is a >necessary complexity for either method. And with a drawback function, that is about the *only* thing you need. >Somebody here was >talking about how hugely complicated it is and how awful >the memory management is and so on...it's not. Again, it's not that it is that hard, it is just totally unnecessary. You've tried to make it sound like draw callbacks are complicated. They aren't. They amount to the same GetAListItem() type processing, plus the draw operation(s). >Why don't you want to use the Dynamic memory? As Ron points out in another thread, it is because there are a number of things even besides hacks which can consume part of the available dynamic memory. Running correctly even under low memory conditions is a prerequisite for passing some application certification tests. It is not that I won't use dynamic memory; I just like to leave for the rest of the application. It seems totally unnecessary to me to use it when a drawlist is simpler (IMHO), does not require the memory, and leaves me free to use effects like fonts, colors, multi-column simulation etc when desirable. >>>When a Custom DrawList is called for (with it's attendant execution >>>for *each* item in the list), >>Wrong. It only gets called for each *visible* item. > >That's what I meant, of course. But it is not what you said or at least implied. The number of visible rows is always low enough that even if GetAListItem() is slower than the equivalent LstGetSelectionText(), the user would never perceive the difference. >GetAListItem is usually far more complicated. It is often >generated (at least in my programs) from non-string fields in >(possibly non-sequential) DB records. Me too. But again it doesn't matter because the number of rows being drawn is low. Whether it is complicated or not doesn't matter. You have to code it once anyway. Once coded, the performance of running it for each visible row has never been a problem, even on slower devices. >What makes you think an *incremental* (aka speed) search is binary? Incremental search, as implemented by Palm OS for popups, is only allowed on lists which are sorted. Whether a binary search would be more efficient than a consecutive search will depend on the number of elements. But either way you'd get the same results. Your contention was that adding the proposed ability to have the OS use a callback for a given item would not be workable and not be able to search effectively or guarantee consistent results. My contention is that it easily could. Now, I'm not the one arguing it should be added. IMHO, lists are fine the way they are. I was refuting your contention it wouldn't work, would have "manifold problems", and "violate instant/interruptable edicts". >>You absolutely would not need a >>fetch of all text, nor would you get inconsistent results. > >No, you would need a fetch of all elements, starting with first, until the first >character >is satisfied with a match. The first time you said "fetch of all text". Now you add "until the first character is satisfied with a match", which was exactly my point. You don't have to fetch all the text unless the first character is higher than anything in the list. >Setting up binary search for this sort of thing does not >have any payback when you have the list in an array... That depends on the size of the list and the distribution of the data. There is not a one-size fits all answer to this. But in general lists should only be used when the number of elements is few enough so that a foward search is sufficient. >On the second character you would have to reset the bounds of the >search and repeatedly bisect, only to find that there are no more >items starting with the (already matched) first character. It's >senseless. That depends on the distribution of the data. There are certainly sets of data where a few leading characters are the same, yet the count is high enough that a binary search is significantly more efficient. >I have it enabled and sitting in front of me. It is not just the visible >parts of the list...It doesn't require a sorted list for the algorithm. But the Palm OS implementation of "incremental search" in a popup does require a sorted list -- or so the docs say. >>Either way, it never has to fetch all the text. > >aaaa >aaaab >aaaac >aaaad >... >aaaaz > >Yes, it does. By "fetch all the text" I understood you to mean the text for all the items in the list. As mentioned previously, using a forward sequential search it can quit when it gets to an entry equal or greater than the search character(s). That to me is not "all the text". With a binary search you also would only test a subset of the entries, not "all the text". >...Yeah but I'm not the one telling the Palm guys that they need >to change the API to suit my implementation (c; I'm not either. I was refuting some of your other contentions or misinformation. Even if they changed the list behavior, unless it was also done via a glue library back to 3.1, I wouldn't use it because I still target 3.1 compatibility. >My listBuilder is proprietary, I won't show it you, .... I'm pretty sure that >is 'less code' than a custom listDraw call back for each list. A custom listdraw callback is trivial. All the work, if you want to call it that, is in the GetAListItem() or equivalent, which as you concede, is generally the same either way. >...the hub-bub about memory management complexity and >leaks is way over done. It's just not that hard. I could say the same about your hub-bub about callback complexity. :) >I don't think the 'Less code' is true. Doesn't take much more than a WinDrawTrunChars, unless I'm also doing other visual effects which are impossible via LstSetListChoices(). >I don't think the faster part is true. In list scrolling, it certainly is not. In scrolling, it is still instantaneous to the user. There just aren't enough visible rows for it to take long enough to be an issue. On the initial form open, there may or may not be enough rows (between all the lists and popups) to have a perceptable delay using your method. With draw callbacks there never is. I think we've beat this horse to death. Either way works. Neither is overly cumbersome. Yours allows incremental search, if a popup list. Mine allows very simple to implement visual effects, multiple columns, etc. You've encapsulated your memory management into a listBuilder routine. I completely avoid needing memory mangement. Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
