Re: LstGetSelectionText() - Memory Allocation ?!?!
On Fri, 08 Aug 2003 14:17:36 -0400, Douglas Handy <[EMAIL PROTECTED]> wrote: >Other programs and records has nothing to do with it. That affects the storage >heap size, not the dynamic memory size. Every Palm OS has the total memory >allocated by the manufacturer with a fixed allotment between storage vs dynamic, >and never the twain shall meet. Well, in the larger sense, you are totally correct. I realized that almost immediately after posting. Addition of applications etc, do (did) affect available heap but not directly or in a large way. It is mostly hacks as you say. >And 7500 bytes from the dynamic heap is NOT just 0.3% of the dynamic memory Again, you are absolutely right. But I want to know, why is it that writing large(ish) programs for four years, using dynamic memory freely for dynamic lists, why haven't I ever run out of heap? *Ever*? One reason, I'm sure, is that I don't consider large lists very practical ergonomic ally. As a matter of coincidence (I'm sure) I hardly ever write an application that uses static lists other than category names... And, BTW, a PIII is my LCD and sits in my cradle as I type. >If your list width becomes 30 bytes instead of 10, that same list now consumes >about 1/4 of potential memory, not .9% (ie three times your quoted .3% for a >width of 10). What if you have several popups on your form? ...and once again, why not use *all* the heap? Have you ever run out? > >In your sample buildList() function, you included the line: > > char *src=GetAListItem(i);//this is simplified for brevity > >If the text is really obtained by an encapsulated call like that, it is trivial 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? It may well require fetching one or more DB records and converting non-readable fields to a human representation and concatenating them. Work once done that is preserved by LstSetListChoices for future reference by LstGetSelectionText() (the cause of this thread) or for incremental search. >to use a drawlist function. Until you want to retrieve the text by index, or you want to enable speed 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. Somebody here was talking about how hugely complicated it is and how awful the memory management is and so on...it's not. >Look ma, no dynamic memory consumed. And you get a prize? How many times have you run out? Why don't you want to use the Dynamic memory? > >>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. "the list" was meant to imply the "visible list" as that is the only part that a custom drawlist callback addresses...one item at a time. >>how much easier/faster is it to simply >>fetch the text from your own store which is already built? > >That depends. It can be extremely simple to fetch the text from the same place >that GetAListItem() gets it. 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. >>>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? > >Sure it is. By definition incremental search only works with a sorted list, >which is precisely where a binary search is very effective. (Consider how >DmFindSortPosition works.) > >>Each character addition would force >>a fetch of all text through the callback... > >Do you have any idea how binary searches work? Yes I do, but you missed the point. What makes you think an *incremental* (aka speed) search is binary? >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. Type a second character, and the second character of the current item is tested and if not satisfied, then the next item is fetched. Setting up binary search for this sort of thing does not have any payback when you have the list in an array... 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. 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. The speed search is as useless or worthwhile as you expect when the data is not in order. It will work until it doesn't, if you take my meaning.
Re: LstGetSelectionText() - Memory Allocation ?!?!
Bullshark, >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, Other programs and records has nothing to do with it. That affects the storage heap size, not the dynamic memory size. Every Palm OS has the total memory allocated by the manufacturer with a fixed allotment between storage vs dynamic, and never the twain shall meet. Applications and records consume storage heap. MemPtrNew() comes from the dynamic heap. And 7500 bytes from the dynamic heap is NOT just 0.3% of the dynamic memory available on a lowly PIII. You're obviously calculating it based on the full 2MB memory size, and that is not the issue. For the record, a Palm III with 2MB total memory has only 122KB of dynamic memory available to MemPtrNew(). And that includes the dynamic memory used for *everything* not in the protected "storage heap". That 122KB is reduced by some OS structures, stacks, hacks, all of your other variables, yada, yada. In reality, that 2MB device has under 100K available to your program for memory allocations. Within that, the largest available contigious chunk will be impacted by how much the garbage collector is constrainsted by locked handles, etc. If your list width becomes 30 bytes instead of 10, that same list now consumes about 1/4 of potential memory, not .9% (ie three times your quoted .3% for a width of 10). What if you have several popups on your form? In your sample buildList() function, you included the line: char *src=GetAListItem(i);//this is simplified for brevity If the text is really obtained by an encapsulated call like that, it is trivial to use a drawlist function. The callback just invokes GetAListItem() then draws it at the coordinates passed to the callback. Look ma, no dynamic memory consumed. >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. Minesweeper or memos has NOTHING to do with it. You can clear off all the other applications and all their associated databases and it won't change the dynamic memory size one byte (unless you disable installed hacks). The dynamic memory size is fixed in the device. Compile options can alter the *stack size* within the total dynamic memory size. It can't change the allocation between storage heap and dynamic memory. >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. And to the range of devices you intend to support. For most 2MB models, that means dynamic heap will typically be under 128KB and must also consider what the OS needs for the stack, open databases, allocated forms, and anything else your program is doing. >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. There is a world of difference, and that is one of the primary reasons it works so well and is fully scalable. Regardless of whether the list has 5 or 50 or 500 or 5000 elements, you only need to obtain the data for the visible rows so at most you're talking a dozen elements on most devices, and typically the visible size is less. Even slow devices can typically collect and redraw the visible rows quick enough for the user to never know the difference during scrolling. And you also never have a delay when first building the list, regardless of the size of the list. You also don't have to free the memory when the form closes. >how much easier/faster is it to simply >fetch the text from your own store which is already built? That depends. It can be extremely simple to fetch the text from the same place that GetAListItem() gets it. And even if somewhat slower per element, you never do it for more than the visible rows at one time, so it becomes almost a moot issue. Also consider a form with multiple popup objects. When you load the form, you don't even have to populate any of the lists. Until the user hits the popup trigger, the OS won't need to run your callback, and then only enough times to fill the visible rows. So on slow devices, you can put up a form *faster* using drawlist then allocating and building each list. And if they never open the popup, you don't have to fetech any elements at all! (You may need GetAListItem() once to obtain a value to show when the popup is closed, but again that is relatively fast.) >>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 realis
Re: LstGetSelectionText() - Memory Allocation ?!?!
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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
Alan Ingleby wrote: > > Ahh... Ok. Yes, the API is never going to give you that functionality... > > If you have a call in your code which will return the text for a given > index, it's not hard to get this functionality anyway. I have this > feature in many of my custom-drawn lists, and support it by having a > "lookup..." field at the bottom of the screen. (Kind of like the > addressbook (That addressbook uses tables, not lists IIRC, but the idea's > the same))... It works well, and requires a fairly small amount of > code... Ah, but you see, incremental search is available only for popup lists (I'm not sure what the rationale is for that restriction), and you can't roll your own for those, because there's no means to intercept List events... > I have to admit that I've never noticed (or missed) the incremental > search feature before. I can't think of any users that would even know > about this ability... I presume if you enable this feature for a suitably > set up list, that the user has no visual cues about this ability being > "turned on"? Unfortunately not. I think the lack of ability to use incremental search with lists that have a null itemsText pointer is one reason why it's so rarely used. If it were used more often, more users would know about it, more users would expect it, and more developers would be encouraged to use it, ad infinitum. :) > 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. Exactly my point; for huge lists, you often don't want to use LstSetListChoices because you're retrieving the strings from somewhere else, and you don't want to deal with the extra memory requirements and management. 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. __ 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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
I doubt they'll every add it, since the existing API is capable of doing the job. 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. Alan "James" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > I really, really wish Lists could have an application-defined callback to > retrieve the text for a specified item. > > Here's how I envision it would work: > > typedef Char* (*ListGetSelectionTextFuncType)(const ListType* listP, Int16 > itemNum, void* userDataP); > > void LstSetListChoices(ListType* listP, Char** itemsText, Int16 numItems, >ListGetSelectionTextFuncType getTextFunc, void* > userDataP); > > getTextFunc would be optional; if NULL, all Lst functions would try to retrieve > strings directly from itemsText. > > The advantage of this system would be that: > 1. there's less need to use a custom drawing function; I'd bet that most >lists with custom-drawn items are purely textual, so the system now >could draw the list items itself > 2. when dealing with pop-up triggers to such lists, the system could >update the trigger label itself > 3. it would allow incremental-search to be used with such lists > > (While I'm wishing, I wish you could set a callback for a pop-up list's event > handler too.) > > #3 is the most important to me. 1 and 2 are not that much extra work with the > current system, but the combination of incremental-search's dependence on a > valid itemsText pointer and the lack of ability to set your own list event > handler makes it really hard to implement 3 yourself. Currently if you want > incremental-search with a dynamically generated list, it's easiest to make > copies of all your strings and suffer the additional memory usage. > > Obviously there's not much that can be done about this for existing versions of > Palm OS, but hopefully this stuff can be changed for Palm OS 6 if it hasn't > been already... > > __ > 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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
On Fri, 8 Aug 2003 11:32:23 +1000, "Alan Ingleby" <[EMAIL PROTECTED]> wrote:
>
>"bullshark" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> Yes I am. Deallocating is:
>>
>> if(pListTxt != NULL) //pretty hard
>{
>>memPtrFree(pListText); //huh?
> pListText=NULL; //??
>}
>Sounds like you're using C++,
No, I'm not. It's straight C.
Here is some psuedo-code. It's been years since I even compiled
my list builder code. It's in CVS someplace and I don't feel like
getting it out, but I did compile this. It gobbles down the
INCREDIBLE sum of 208 bytes of code space.
char** buildList(int listWidth,int cnt){
int amt=cnt*(sizeof(char*)+(listWidth+1));
int i;
char **theList=(char**)MemPtrNew(amt);
char *dest=(char*)(&theList[cnt]);
//If you want to be stingy:
// WARNING: *Grossly* complicates the deallocation to TWO
// statements:
//MemPtrFree(theList[0]);
//MemPtrFree(theList);
//char **theList=(char**)MemPtrNew(cnt*sizeof(char**));
//char *dest=(char*)MemPtrNew(cnt*listWidth+1);
//UInt32 memUsed=0;
for(i=0;iand also violates the coding practice of trying to unallocate
>memory from within the same function in which it was allocated.
You evidently have no experience with 'Lazy evaluation'.
Never heard of your 'coding practice'.
The fact is, if the global is not null, there is memory allocated to the list.
You need to de-allocate before allocating again. If you like, I'll
move the clause to a separate function, OK?
Your '??' on the setting of pListText to NULL makes me think
you don't get it;
Leaving the de-allocation of the prior list to the list builder
function is what makes memory handling simple. Any time you build
a list, it cleans itself.
>I'm not
>saying either way is wrong... Just offering reasons why some people choose
>different methods.
What you *are* saying is that you don't have much experience with
allocating/deallocating memory for dynamic lists.
bullshark
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
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 binar
Re: LstGetSelectionText() - Memory Allocation ?!?!
bullshark wrote: > > The source code for the standard applets are testaments to "the > way". Well, the sample Preference panel code uses the custom-drawn-list model... > 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. Good points, but the current incremental search implementation puts the responsibility on the developer to ensure that the list is already sorted. Using a callback mechanism shouldn't be much different; the developer's responsible to make the necessary steps to make incremental-search well-behaved. > 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. I am fully capable of dealing with all that. However, it's a chore. Feeding LstSetListChoices a copy of your strings means that there are extra pointers to pass around, extra memory to remember to deallocate later, extra error checks for the extra allocation(s). It's not /hard/, it's just tedious and a bit more error-prone. (And by the extra pointers, I don't mean a separate allocation for each string (that would be silly). If there's data you want to associate with each list item, instead of a single array of structs, you now would need one array for the strings and another array for the corresponding values.) > ...Yeah but I'm not the one telling the Palm guys that they need > to change the API to suit my implementation (c; Well: 1. It's just a suggestion. 2. Based on the number of other replies, I think the custom-drawn-list is a fairly common usage pattern. __ 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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
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, populate these blocks in some way, grab pointers to all of them, and then call LstSetListChoices? (Don't forget, then you have to worry about deallocation when the form exits.) If you have a small number of list items, it works well enough I imagine. If you have a large number, it certainly doesn't sound easier to me than custom draw lists. You have to allocate space, clear the space, copy the strings to it, and then hand the pointers to LstSetListChoices, not to mention remembering to deallocate the memory. I'd rather not clutter up dynamic memory with any more locked blocks than I must. > 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. Until your program is done, you're never sure exactly how much memory it will require. Why burn memory when you don't need to? There's not enough dynamic memory on the Palm as it is. > So is LstSetListChoices. Quite a bit easier, in fact. You're not taking into account allocation/assigning strings/deallocation. That doesn't sound remarkably easier to me unless you're forced to keep the strings in dynamic memory already for whatever reason. > 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. > But it's your program, do as you like. Well, gosh, thanks, that's mighty big of you. -Ken -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
Ah, but you see, incremental search is available only for popup lists (I'm not sure what the rationale is for that restriction), and you can't roll your own for those, because there's no means to intercept List events... Popup lists have their own modal event loops, which means they have a handler that can actually accept the keystrokes and do the search. To do automatic incremental search for non-popup lists, the OS would need a mechanism to direct keystrokes to the list control. -- Ben Combee <[EMAIL PROTECTED]> CodeWarrior for Palm OS technical lead Palm OS programming help @ www.palmoswerks.com -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
"bullshark" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yes I am. Deallocating is:
>
> if(pListTxt != NULL) //pretty hard
{
>memPtrFree(pListText); //huh?
pListText=NULL; //??
}
> 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.
Sounds like you're using C++, in which case deallocating such memory is
easily done in a destructor, but using C however requires the use of
globals, and also violates the coding practice of trying to unallocate
memory from within the same function in which it was allocated. I'm not
saying either way is wrong... Just offering reasons why some people choose
different methods.
Have a nice day :-)
Alan
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
"James" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > If there is a simple way to have incremental-search with the existing API > without passing the actual text to LstSetListChoices, please elaborate. Can you please clarify what you mean by incremental search. Alan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
"James" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Alan Ingleby wrote: > > > > "James" wrote: > > > > > > If there is a simple way to have incremental-search with the existing > > > API without passing the actual text to LstSetListChoices, please > > > elaborate. > > > > Can you please clarify what you mean by incremental search. > > http://www.palmos.com/dev/support/docs/palmos/List.html#1042652 > http://www.palmos.com/dev/support/docs/palmos/PalmOSGlueLib.html#1393337 Ahh... Ok. Yes, the API is never going to give you that functionality... If you have a call in your code which will return the text for a given index, it's not hard to get this functionality anyway. I have this feature in many of my custom-drawn lists, and support it by having a "lookup..." field at the bottom of the screen. (Kind of like the addressbook (That addressbook uses tables, not lists IIRC, but the idea's the same))... It works well, and requires a fairly small amount of code... I have to admit that I've never noticed (or missed) the incremental search feature before. I can't think of any users that would even know about this ability... I presume if you enable this feature for a suitably set up list, that the user has no visual cues about this ability being "turned on"? Much nicer to roll-your-own when you think a user will benefit from the feature... All of my dynamic lists can then use the same "boilerplate" code... 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. Alan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
Alan Ingleby wrote: > > "James" wrote: > > > > If there is a simple way to have incremental-search with the existing > > API without passing the actual text to LstSetListChoices, please > > elaborate. > > Can you please clarify what you mean by incremental search. http://www.palmos.com/dev/support/docs/palmos/List.html#1042652 http://www.palmos.com/dev/support/docs/palmos/PalmOSGlueLib.html#1393337 __ 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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
On 04 Aug 2003 14:55:54 +0100, kcorey <[EMAIL PROTECTED]> wrote: > >On Mon, 2003-08-04 at 14:53, bullshark wrote: >> On Mon, 4 Aug 2003 09:59:53 +1000, "Alan Ingleby" <[EMAIL PROTECTED]> wrote: >> > >> >Ken's right. Specifically, you *can't* use LstGetSelectionText with a >> >dynamic list, so don't. >> >> What? Why would that be? That's just wrong. >> >> This is only the case when a (suspicious) program never calls LstSetListChoices. >> I think there is foul play here. >[...] >> If all that is involved here is a dynamic list, a DrawList callback >> is the wrong way to do it. You would only resort to this if your list >> had to display little icons or something. Even if you are doing it the >> wrong way, LstSetListChoices should still be called unless the list >> items don't have any text. > >It all depends on where your strings come from. > >Lately, I've done a bunch of work on lists built up from strings that >are individual records in a database. > >If I wanted to be able to use LstSetListChoices, I'd need to either >1) Have a String array. That's not dynamic. >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. >3) Open all the records, and lock them in place while the list is on the >form. What? > >All of these take up some amount of space. Arguably, if you're only >going to display 10 items, big woop. If you're going to display up to >100, now you're potentially chewing up large amounts of memory. 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'? >Using a custom-drawn list gets around this nicely, It gets around a problem that doesn't really need solving. >and it's a piece of >cake, So is LstSetListChoices. Quite a bit easier, in fact. > also giving you the ability to draw graphics, change fonts, or do >whatever bit of wizardry you'd like in the list. That's not 'wizardry', but if you need icons or funny fonts, a custom Drawlist is the way to do it. That is what it's for. >Besides, do it once, and the code for the custom drawn list become >boiler plate, as the functionality is quite similar. 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. But it's your program, do as you like. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
"James" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Exactly my point; for huge lists, you often don't want to use LstSetListChoices > because you're retrieving the strings from somewhere else, and you don't want > to deal with the extra memory requirements and management. 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. I agree totally with your point, but really Don't go holding your breath for this to be implemented PalmSource surely know about this issue, but I'm sure they've put it down to "you can work around it if you really need to". I see your point about popup lists, and I'll say again, you can fake it by not using a popup list, but providing the same functionality with a normal list... But who want to do that huh? Alan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
On Mon, 04 Aug 2003 16:32:34 -0400, Douglas Handy <[EMAIL PROTECTED]> wrote: >Bullshark, > >>>Ken's right. Specifically, you *can't* use LstGetSelectionText with a >>>dynamic list, so don't. > >That should probably read you *can't* use LstGetSelectionText when you supplied >NULL as the itemsText pointer to LstSetListChoices. Yes, it certainly *SHOULD*, because as stated, it is out and out wrong. >>If all that is involved here is a dynamic list, a DrawList callback >>is the wrong way to do it. > >Personal opinion. Earlier, a link was made to a "recipe" on the Pam OS site >which describes static content lists, dynamic content lists, and custom-drawn >content. (See http://www.palmos.com/dev/support/docs/recipes/lists.html#dynamic >for example.) You really need to read for context: What was the FIRST CLAUSE of my statement? The article is misleading, and subject to interpretation. There is no need to "remember" to deallocate the list at form close time, unless the form is so trivial that it is never revisited..."lazy instantiation (and deallocation)" takes care of this. The method for allocating the list used in the article is terrible The entire chunk can be allocated and deallocated in one call. Repetitive calls to memptrnew/free were positively gross, and I guess, purpose built to suit the agenda of the author. That method would make the worst possible case for memory waste as well. I seriously suspect that the author of that "Recipe" is not a "Cook". The article is a near total waste of electrons. The simple truth of the matter is that if you need the text from the list (As the OP for this thread does), DrawList is the Wrong Way to Do it. IFF your list corresponds one to one with DB records AND the DB records have the text *exactly* as needed AND the list is not frequently used AND the list is not large, then the DrawList is an acceptable substitute. > In many cases, a drawlist is a trivial way to do it. On that we agree. Trivial programs should benefit. >by simply >using the item number to map to a record index in the database, grab the data, >and draw it. That's pretty convenient. You only always display everything. What happens when your list data is not from sequential records, or does not map to a database record? What a lot of work for every tap on a list. It's you program do as you like. In the mean time I will state my opinion as I see fit. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
I really, really wish Lists could have an application-defined callback to retrieve the text for a specified item. Here's how I envision it would work: typedef Char* (*ListGetSelectionTextFuncType)(const ListType* listP, Int16 itemNum, void* userDataP); void LstSetListChoices(ListType* listP, Char** itemsText, Int16 numItems, ListGetSelectionTextFuncType getTextFunc, void* userDataP); getTextFunc would be optional; if NULL, all Lst functions would try to retrieve strings directly from itemsText. The advantage of this system would be that: 1. there's less need to use a custom drawing function; I'd bet that most lists with custom-drawn items are purely textual, so the system now could draw the list items itself 2. when dealing with pop-up triggers to such lists, the system could update the trigger label itself 3. it would allow incremental-search to be used with such lists (While I'm wishing, I wish you could set a callback for a pop-up list's event handler too.) #3 is the most important to me. 1 and 2 are not that much extra work with the current system, but the combination of incremental-search's dependence on a valid itemsText pointer and the lack of ability to set your own list event handler makes it really hard to implement 3 yourself. Currently if you want incremental-search with a dynamically generated list, it's easiest to make copies of all your strings and suffer the additional memory usage. Obviously there's not much that can be done about this for existing versions of Palm OS, but hopefully this stuff can be changed for Palm OS 6 if it hasn't been already... __ 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/
Re: LstGetSelectionText() - Memory Allocation ?!?!
Bullshark, >>Ken's right. Specifically, you *can't* use LstGetSelectionText with a >>dynamic list, so don't. That should probably read you *can't* use LstGetSelectionText when you supplied NULL as the itemsText pointer to LstSetListChoices. >If all that is involved here is a dynamic list, a DrawList callback >is the wrong way to do it. Personal opinion. Earlier, a link was made to a "recipe" on the Pam OS site which describes static content lists, dynamic content lists, and custom-drawn content. (See http://www.palmos.com/dev/support/docs/recipes/lists.html#dynamic for example.) The last paragraph of the dynamic content method states: "The complexity resulting from having to remember to free the list choices often makes this technique worse than having a custom drawing routine for the list. However, this way works much better than having a custom drawing routine if the list of choices is slow to generate or must be generated sequentially." >To set dynamic list text, create the list when the need arises and >call LstSetListChoices(). Keep your program simple and let the >OS do the work. IMHO, using custom draw lists is often *simpler* than creating the text, populating the list, and freeing the memory later.While the recipe caveat of this not necessarily being true when the list is slow to generate, in my experience that has never been a problem. >I don't have any DrawList functions and I have dozens of Dynamic lists. And I have plenty of drawlist functions and zero using the method you prefer. >Even then, if they contain text, LstSetListChoices should be called >in most cases. It is the obvious place to store the text component of the >custom drawn list and simplifies the job of the DrawList callback. No it doesn't. In cases where you have a database (or database subset) containing the data, you just read the appropriate database record and draw the value at the coordinates passed to the drawlist function. This takes zero additional memory allocation to hold the list of choices, regardless of the size of the list or database, and you never have to free the memory either. It has the added benefit of letting you change fonts or colors, simulate multi-colum lists easily, etc. Very similar to drawing table rows. Calling a drawlist function "the wrong way to do it" for a dynamic content list is a disservice. In many cases, a drawlist is a trivial way to do it by simply using the item number to map to a record index in the database, grab the data, and draw it. Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
*click* ... that was the sound made when I figured out what the past few posts were all about Becuase the list is generated from the databse, I'm taking the list selection UInt16 return value to get the record number at that exact location... Excellent ladies and gents...excellent. Thanks again. I love it when a plan comes together... ;) Nole kcorey <[EMAIL PROTECTED]>To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent by: cc: (bcc: Nole Mailey/pmc) [EMAIL PROTECTED]Subject: Re: LstGetSelectionText() - Memory Allocation ?!?! palmos.com 08/04/2003 08:55 AM Please respond to "Palm Developer Forum" On Mon, 2003-08-04 at 14:53, bullshark wrote: > On Mon, 4 Aug 2003 09:59:53 +1000, "Alan Ingleby" <[EMAIL PROTECTED]> wrote: > > > >Ken's right. Specifically, you *can't* use LstGetSelectionText with a > >dynamic list, so don't. > > What? Why would that be? That's just wrong. > > This is only the case when a (suspicious) program never calls LstSetListChoices. > I think there is foul play here. [...] > If all that is involved here is a dynamic list, a DrawList callback > is the wrong way to do it. You would only resort to this if your list > had to display little icons or something. Even if you are doing it the > wrong way, LstSetListChoices should still be called unless the list > items don't have any text. It all depends on where your strings come from. Lately, I've done a bunch of work on lists built up from strings that are individual records in a database. If I wanted to be able to use LstSetListChoices, I'd need to either 1) Have a String array. 2) Allocate an array from dynamic memory for the strings and copy all the strings into memory. 3) Open all the records, and lock them in place while the list is on the form. All of these take up some amount of space. Arguably, if you're only going to display 10 items, big woop. If you're going to display up to 100, now you're potentially chewing up large amounts of memory. Using a custom-drawn list gets around this nicely, and it's a piece of cake, also giving you the ability to draw graphics, change fonts, or do whatever bit of wizardry you'd like in the list. Besides, do it once, and the code for the custom drawn list become boiler plate, as the functionality is quite similar. -Ken -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
> Another thought, though...if you're having trouble reading from the
> list, why try to read from the list? If you have it dynamically loading
> correctly, those strings need to be available to you in some other way
> (database, string array, string resource...something) so why not read
> them from the same location?
> -Ken
My current setup saves the records (packed) to a database.
>From there, I generated a list dynamically by calling:
DmNumRecordsInCategory();
LstSetListChoices();
LstSetDrawFunction();
where my draw function...
Seeks through all the records...
DmSeekRecordInCategory();
DmQueryRecord();
and after unpacking...
DrawCharsToFitWidth();
My goal is to determine which item in the list was chosen, get the key
from that info and pull up a record from another database? So I thought I
could just copy the string using StrCopy(listText,
LstGetSelectionText(list,LstGetSelection(list)))
But I can't figure out how I'm supposed to allocate the memory properly?
If I go:
listText MemPtr(sizeof(LstGetSelectionText(list,LstGetSelection(list
I get a return value of 4, which I thought was the size of the pointer...
I'm getting way off track here... but I'm at a loss here. How do I access
this info?
Thanks for all feedback thus far.. :)
Nole
kcorey
<[EMAIL PROTECTED]>To: "Palm Developer Forum"
<[EMAIL PROTECTED]>
Sent by: cc: (bcc: Nole
Mailey/pmc)
[EMAIL PROTECTED]Subject: Re: LstGetSelectionText() -
Memory Allocation ?!?!
palmos.com
08/04/2003 08:55 AM
Please respond to "Palm Developer
Forum"
On Mon, 2003-08-04 at 14:53, bullshark wrote:
> On Mon, 4 Aug 2003 09:59:53 +1000, "Alan Ingleby"
<[EMAIL PROTECTED]> wrote:
> >
> >Ken's right. Specifically, you *can't* use LstGetSelectionText with a
> >dynamic list, so don't.
>
> What? Why would that be? That's just wrong.
>
> This is only the case when a (suspicious) program never calls
LstSetListChoices.
> I think there is foul play here.
[...]
> If all that is involved here is a dynamic list, a DrawList callback
> is the wrong way to do it. You would only resort to this if your list
> had to display little icons or something. Even if you are doing it the
> wrong way, LstSetListChoices should still be called unless the list
> items don't have any text.
It all depends on where your strings come from.
Lately, I've done a bunch of work on lists built up from strings that
are individual records in a database.
If I wanted to be able to use LstSetListChoices, I'd need to either
1) Have a String array.
2) Allocate an array from dynamic memory for the strings and copy all
the strings into memory.
3) Open all the records, and lock them in place while the list is on the
form.
All of these take up some amount of space. Arguably, if you're only
going to display 10 items, big woop. If you're going to display up to
100, now you're potentially chewing up large amounts of memory.
Using a custom-drawn list gets around this nicely, and it's a piece of
cake, also giving you the ability to draw graphics, change fonts, or do
whatever bit of wizardry you'd like in the list.
Besides, do it once, and the code for the custom drawn list become
boiler plate, as the functionality is quite similar.
-Ken
--
For infor
Re: LstGetSelectionText() - Memory Allocation ?!?!
On Mon, 2003-08-04 at 14:53, bullshark wrote: > On Mon, 4 Aug 2003 09:59:53 +1000, "Alan Ingleby" <[EMAIL PROTECTED]> wrote: > > > >Ken's right. Specifically, you *can't* use LstGetSelectionText with a > >dynamic list, so don't. > > What? Why would that be? That's just wrong. > > This is only the case when a (suspicious) program never calls LstSetListChoices. > I think there is foul play here. [...] > If all that is involved here is a dynamic list, a DrawList callback > is the wrong way to do it. You would only resort to this if your list > had to display little icons or something. Even if you are doing it the > wrong way, LstSetListChoices should still be called unless the list > items don't have any text. It all depends on where your strings come from. Lately, I've done a bunch of work on lists built up from strings that are individual records in a database. If I wanted to be able to use LstSetListChoices, I'd need to either 1) Have a String array. 2) Allocate an array from dynamic memory for the strings and copy all the strings into memory. 3) Open all the records, and lock them in place while the list is on the form. All of these take up some amount of space. Arguably, if you're only going to display 10 items, big woop. If you're going to display up to 100, now you're potentially chewing up large amounts of memory. Using a custom-drawn list gets around this nicely, and it's a piece of cake, also giving you the ability to draw graphics, change fonts, or do whatever bit of wizardry you'd like in the list. Besides, do it once, and the code for the custom drawn list become boiler plate, as the functionality is quite similar. -Ken -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
On Mon, 4 Aug 2003 09:59:53 +1000, "Alan Ingleby" <[EMAIL PROTECTED]> wrote:
>
>Ken's right. Specifically, you *can't* use LstGetSelectionText with a
>dynamic list, so don't.
What? Why would that be? That's just wrong.
This is only the case when a (suspicious) program never calls LstSetListChoices.
I think there is foul play here.
If all that is involved here is a dynamic list, a DrawList callback
is the wrong way to do it. You would only resort to this if your list
had to display little icons or something. Even if you are doing it the
wrong way, LstSetListChoices should still be called unless the list
items don't have any text.
To set dynamic list text, create the list when the need arises and
call LstSetListChoices(). Keep your program simple and let the
OS do the work.
>Use your own code to determine the value. This shouldn't be hard, as it's
>effectively the same code you're using in your DrawList function.
I don't have any DrawList functions and I have dozens of Dynamic lists.
Drawlist methods are not related to dynamic lists. Drawlist callbacks are
for list choices that don't contain text or can't be displayed as a text
string. Even then, if they contain text, LstSetListChoices should be called
in most cases. It is the obvious place to store the text component of the
custom drawn list and simplifies the job of the DrawList callback.
A program could have many 'dynamic lists' that are set into the list
depending on events at another control. LstGetSelectionText() is
free of charge, provides correct results with respect to the last
set of elements given and eliminates the need to remember or organize
this programmatically.
The supplied code is riddled with unchecked possibilities for failure.
*
Char *listText;
ListType *list = GetObjectPtr(ListOrderList);
//What is GetObjectPtr?
//how do you know it succeeded?
//Why isn't there a cast to ListPtr?
//ListOrderList doesn't sound like a resourceID
//Is it a Popup list? Did you note the warning about
//FrmGetActiveForm() in the comments in FrmGetActiveForm()?
listText = MemPtrNew(50);
//what a giant memory leak. There is no attempt to deallocate.
//why are you allocating dynamically?
//How do you know the allocation succeeded?
// Char listText[50] will work just as well
//if dynamic allocation is mandatory, then why not allocate what's needed
//e.g.
// {
// if(listText != NULL){ //assuming listText is a global...
// MemPtrFree(listText);// take care of this memory leak
// listText=NULL;
// }
// int n=LstGetSelection(list);
// if( n!=noListSelection ){
// CharPtr cp=LstGetSelectionText(list,n);
// ErrFatalDisplayIf(cp==NULL,"GetSelectionText failed");
// listText=(CharPtr)MemPtrNew(StrLen(cp)+1);
// ErrFatalDisplayIf(listText==NULL,"Could'nt allocate listText");
// StrCopy(listText,cp);
// }
// }
StrCopy(listText, LstGetSelectionText(list,LstGetSelection(list)));
// what if nothing is selected?
*
regards
bullshark
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
Ken's right. Specifically, you *can't* use LstGetSelectionText with a dynamic list, so don't. Use your own code to determine the value. This shouldn't be hard, as it's effectively the same code you're using in your *DrawList function. Alan "kcorey" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > On Sun, 2003-08-03 at 00:32, [EMAIL PROTECTED] wrote: > > I've got my list generating dynamically... HOORAY! However now > > I'm trying to get the text that the user selects... > > > > I'm not sure what I'm doing wrong in the text memory allocation side > > of things or how to do it properly anyways...but I know that's my > > problem... > > Not sure what your 'GetObjectPtr' function does...perhaps it's not > returning the correct ListType *? Does it do a > FrmGetObjectPtr(formPtr, FrmGetObjectIndex(formPtr, objectID)) at its > heart? > > Are you checking the return values that these functions are returning? > If one of these functions fails for whatever reason, perhaps there's a > clue there. > > Another thought, though...if you're having trouble reading from the > list, why try to read from the list? If you have it dynamically loading > correctly, those strings need to be available to you in some other way > (database, string array, string resource...something) so why not read > them from the same location? > > -Ken > > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstGetSelectionText() - Memory Allocation ?!?!
On Sun, 2003-08-03 at 00:32, [EMAIL PROTECTED] wrote: > I've got my list generating dynamically... HOORAY! However now > I'm trying to get the text that the user selects... > > I'm not sure what I'm doing wrong in the text memory allocation side > of things or how to do it properly anyways...but I know that's my > problem... Not sure what your 'GetObjectPtr' function does...perhaps it's not returning the correct ListType *? Does it do a FrmGetObjectPtr(formPtr, FrmGetObjectIndex(formPtr, objectID)) at its heart? Are you checking the return values that these functions are returning? If one of these functions fails for whatever reason, perhaps there's a clue there. Another thought, though...if you're having trouble reading from the list, why try to read from the list? If you have it dynamically loading correctly, those strings need to be available to you in some other way (database, string array, string resource...something) so why not read them from the same location? -Ken -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
LstGetSelectionText() - Memory Allocation ?!?!
I've got my list generating dynamically... HOORAY! However now I'm trying to get the text that the user selects... I'm not sure what I'm doing wrong in the text memory allocation side of things or how to do it properly anyways...but I know that's my problem... * Char *listText; ListType *list = GetObjectPtr(ListOrderList); listText = MemPtrNew(50); StrCopy(listText, LstGetSelectionText(list,LstGetSelection(list))); * Now, this compiles okay, of course. But it's saying: "just read from memory location .blah blahwhich is in low memoryblah" So now this tells me I'm not allocating the memory properly... correct? Can anyone tell me what I'm doing wrong? Thanks. :) Nole -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
