Alan Ingleby wrote: > > I doubt they'll [ever] add it, since the existing API is capable of doing > the job.
If there is a simple way to have incremental-search with the existing API without passing the actual text to LstSetListChoices, please elaborate. > Besides that, it's possible to simulate a "text callback" using the > existing API.. Simply use the userDataP to hold your function pointer, > then you only need to write one ListDraw function (which then calls your > "text callback"). > > Easy huh?.. Take about 15 minutes to write it the first time, stick it > into your standard "library" code, get the exact functionality you need, > and it only adds 10 lines of code to your whole project. I already stated that the custom list drawing stuff was easily implemented. Using a custom list drawing function is not much work and isn't my complaint; it was merely an example of where a callback could help, even if only slightly. My complaint is that the OS often is dependent on having access to the list text, such as when it automatically sets popup trigger labels on popSelect events and when it performs incremental-search. The system can't do these things when the list choices are null. Yes, setting the trigger label yourself is easy, but it's annoying, and really, if the API were designed a little better it wouldn't be necessary at all. On the other hand, there's no clear means to finagle support for incremental-search short of making copies of all your strings and passing the lot of them to LstSetListChoices. Furthermore, as incremental-search is most useful for long lists of items, those are precisely the types of lists for which you don't want to have doubled memory requirements. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
