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;icnt;i++){
int itemLen;
char *src=GetAListItem(i);//this is simplified for brevity
StrNCopy(dest,src,listWidth);
theList[i]=dest;
itemLen=StrLen(dest)+1;
dest+=itemLen;
//if you want to be stingy:
//memUsed+=itemLen
}
// If you want to be stingy:
// MemPtrResize(theList[0],memUsed);
return theList;
}
If you want to get really ooky for no particular reason,
you can use handles and lock them.
and 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: LstSetListChoices
On Fri, 8 Aug 2003 09:51:28 -0700, Dave Carrigan [EMAIL PROTECTED] wrote: On Fri, Aug 08, 2003 at 12:26:13PM -0400, bullshark wrote: static char* gPlateString = PL3/16x\0PL1/4x\0PL5/16x\0PL3/8x\0PL1/2x\0PL5/8x\0; The above doesn't work. The compiler knows that dquote strings end with \0 so there is nothing in the .o image after PL3/16x. What are you talking about? That's simply not true for any C compiler I've ever seen. You're absolutely right (I just checked), thanks for correcting that. It's one of those I been programming too long memories... somewhere, someplace, I have a compiler that failed to include dquoted text following an embedded '\0', but it ain't this one It's still a cumbersome thing, hard to read, and fraught with peril. What happens if the following character is numeric, instead of a 'P'? ...it's probably that kind of 'gotcha' that forever purged my consciousness of that type of expression (c: 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 ?!?!
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 ?!?!
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: MemHandleSize - MemHandleResize
On Fri, 8 Aug 2003 10:35:28 -0300, rguevara [EMAIL PROTECTED] wrote: I have some questions about those functions: MemHandleSize work over one chunk unlocked? Documentation is silent on locked vs unlocked. It should work either way, if i do: recordH = DmGetRecord(PedidosDB, NuevoIndice); and later: length=(MemHandleSize(registroH) 'recordH' is not the same as 'registroH'. If you are using two names to refer to the same handle, then perhaps you are mixing them up. If DmReleaseRecord is called the Handle may not be valid anymore. +StrLen(item.items[gcantitems-1].codigo)+1 +sizeof(item.items[gcantitems-1].cantidad) +sizeof(item.items[gcantitems-1].precio)); i get: (1.0) called SysFatalAlert with the message: MemoryMgr.c, Line:4359, Free handle and (continue) i get: (1.0) just read from memory location 0x0144, causing a bus error. (reset) ¿? if later MemHandleResize work with this handle without problems in other case You probably shouldn't do that. Use DmResizeRecord to change record sizes. You might get away with it, but run into trouble later. 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 ?!?!
to the prior top-hit. Whether a binary search or sequential search would be preferable will depend on the number of items in the list, but the OS knows that too. Either way, it never has to fetch all the text. b c d ... z Yes, it does. The code is already there. The API already does what you want. Applications that use LstSeListChoices() use it freely, because it costs nothing. It costs dynamic memory, which can be a real issue in 2MB devices (or earlier, but I don't worry about them...). Like I said, though my code is full of tests for heap failure, I have yet to see one. It also costs time when the form is opened, 1) irrelevant IMO, nobody cares if a program takes a few Ms to load. They care how it works, and if it has the features they expect. 2) Lazy evaluation, I never build the lists until the form they are on is opened and occasionally, not until they are popped. I haven't seen any perceptible delays in program loading, form switching or list appearance. But then again, I don't make huge lists...anything large generally winds up in a scrolling table, or has some method to 'drill' the presentation set to something manageable. The materials that I work on demand more context than a single word. I've been writing for the palm for several years. Then how could you not understand the difference between storage heap and dynamic heap on a Palm OS device? That's a mistake born of not having been interested in those aspects for several years. I work on a half dozen platforms, and though I knew my mistake almost as soon as I posted, it has no effect on the position...In fact, the mistake was made in an attempt to concede a weakness - i.e. that available heap may shrink over time. You have quite rightly eliminated that weakness. I remain steadfast in my conviction that LstSetListChoices should be used in all but the most trivial cases. Aside from design-time static lists (the most trivial cases...), I remain steadfast in my conviction that drawList is the preferred method. Of course, this also means I am not using incremental search. and the best way to get there, with the smallest amount of code is to use the API the way it's designers intended. And the least amount of code to get there is to use your GetAListItem() inside a callback, and just draw the string at the coordinates given. All the rest of your code is completely unnecessary, consumes dynamic memory, and forces the form open routine to fetch all the rows for every list and popup. ...Yeah but I'm not the one telling the Palm guys that they need to change the API to suit my implementation (c; My listBuilder is proprietary, I won't show it you, or even the method signature, but there is only one copy of that code in any program and except for one case, it (alone)supports all the dynamic lists in all the forms. I'm pretty sure that is 'less code' than a custom listDraw call back for each list. I already showed the basic structure that permits lazy evaluation, single pointer allocation and deallocation...the hub-bub about memory management complexity and leaks is way over done. It's just not that hard. I maintain it is *faster* to only fetch rows as they are needed (or *if* needed!), it conserves memory, avoids the need to free memory or have a memory leak, and takes *less* code to implement besides! I don't think the 'Less code' is true. I don't think the faster part is true. In list scrolling, it certainly is not. I don't see the value in not using an available resource, but you're right, it consumes memory. Memory which (as I understand it) was put there to be used. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Palm ZIRE dynamic heap size
On Fri, 8 Aug 2003 11:25:40 +0300, HermesPalm [EMAIL PROTECTED] wrote: Hi all, can anyone tell me how much dynamic memory has a Palm Zire with only 2 MB of memory, OS 4.1 No. Available memory depends on memory use. It's not a fixed number. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: LstSetListChoices
On Thu, 7 Aug 2003 23:46:16 -0700, Steve K [EMAIL PROTECTED] wrote:
I have read many a posts on this question, however, none seem to be working
for me. I have attempted to simplify this with no results. I am no longer
getting fatal exceptions, however nothing is happening.
What is the key ingredient i'm missing here?
static char* gPlateString =
PL3/16x\0PL1/4x\0PL5/16x\0PL3/8x\0PL1/2x\0PL5/8x\0;
The above doesn't work. The compiler knows that dquote strings end with \0
so there is nothing in the .o image after PL3/16x. If you want to do it that
way:
static char gPlateString[]={'P','L','3','/','1','6','x',0,'P'
Putting this in the resource file as a StringTable would be easier though.
static char** gListString;
static Boolean PopulateList(void)
{
FormType* frmP = FrmGetActiveForm();
ListType* lstP = (ListType*) FrmGetObjectPtr(frmP, lstDesc);
gListString = (char**) MemPtrNew(StrLen(gPlateString));
No. You have confused/combined two different methods:
With gPlateString re-stated as above, you are prepared
for SysFormPointerArrayToStrings(). This is all you do:
MemHandle h=SysFormPointerArrayToStrings(gPlateList,6);
ErrFatalDisplayIf(h==0,SysFormPointerArrayToStrings failed);
gListString=MemHandleLock(h);
LstSetListChoices(lstP, gListString,6);
// when you are done with the list, unlock the handle and call MemHandle Free
// SysForm allocated it for you, disposal is your problem
If you are going to allocate yourself:
// this looks more complicated than it really is.
//declare the strings like this instead:
char *gPlateString[] ={PL3/16x,PL1/4x,PL5/16x,PL3/8x,PL1/2x,PL5/8x};
...in your function:
char *dst;
int i;
// you can get the count automatically
int cnt=sizeof(gPlateList)/sizeof(char*); //this will be 6
//you have 6 strings in your list
//so you need room for 6 char *
int amt = cnt*sizeof(char*);
//each of the elments is 7 characters long plus the terminating zero total(8)
amt += cnt*8;
gListString= MemPtrNew( amt ); //this is big enough for 6 char* + 6 strings of 7
chars
dst=(char*)(gListString[cnt]); //point to first byte after the 6th char *
for(i=0; icnt; i++){
StrCopy(dst,gPlateString[i]); //copy in the text
gListString[i]=dst; //make gListString[i] point to the copied text
dst+=8; //adjust dst to point to the next byte after the
terminating zero.
//we could useStrLen(dst)+1..I'm just simplifying
}
// when you are done with this list, call MemPtrFree(gListString);
If we pretend that char* uses two bytes(for simplicity), you allocated 12+48=60 bytes
(3C)
Your allocated memory now looks like this (in hex)
PL3/16x\0PL1/4x\0PL5/16x\0PL3/8x\0PL1/2x\0PL5/8x\0;
These are the Char *'s (and they point to the data that follows):
v
02468ACE
: 000C 0014 001C 0024 002C 0034 'PL' '3/'
0010: '16' 'x'0 'PL' '1/' '4x' 'PL' '5/'
0020: '16' 'x'0 'PL' '3/' '8x' 'PL' '1/'
0030: '2x' 'PL' '5/' '8x'
We wasted four bytes by allocating 8 bytes per string
when four of them only had 7...but what the heck. If you
want, you can track the actual string lengths and call
MemPtrResize() with the final tally, but it's not worth the
trouble for a list this small.
gListString = (char**) SysFormPointerArrayToStrings(gPlateString, 6);
Double No. SysFormPointerArrayToStrings allocates and return a Handle.
See above. Either allocate yourself, or use SysForm...not both
and the Handle that it returns needs to be locked before use in
LstSetListChoices.
LstSetListChoices(lstP, gListString, 6);
LstDrawList(lstP);
return true;
}
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 ?!?!
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 ?!?!
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 ?!?!
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: Newbie Question - Using Visual Studio??
On Thu, 31 Jul 2003 21:50:35 +0100, Paul Johnson [EMAIL PROTECTED] wrote: itself. I'd buy slickedit - its cheap and good and geared up to running other compilers (it's purely an editor) :) 10-4 on that. Best software I own. I haven't upgraded to the latest though. After asking them to support gnu stuff directly for years, they finally do. I was too lazy to write the scripts myself. though I did write extensions for rcp files (auto complete/coloring etc) Have used it successfully with the m68k-palmos-gdb for source level debugging? I asked them about it, and got unclear responses. I use vs for everything except that, where I use emacs. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Very Persistant Problem
On Wed, 30 Jul 2003 08:19:42 -0400, Dave Mottorn [EMAIL PROTECTED] wrote: and just about everything I can think of but I still don't get any response to tapping those two controls. Has anyone ever seen anything like this? The most obvious problem would be mistaken identity. Next would be an infamous ==/= semantic error in the 'if() clause. bullshark -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: help: getting nilEvents when I don't need any !
On Mon, 07 Jul 2003 23:45:11 -, alexrousseau_jta [EMAIL PROTECTED] wrote: Still, bugs me quite the bit as I am trying to optimize my application (tight animation loops and all), and am figuring that some machine cycles are spent hosting some totally uninvited guest. The default return from your handler is false, and the default case in your switch is break. If you are trying to optimize, the first order of business is to not handle cases you don't want. By putting the nil event in as a case, you're the one consuming unnecessary cycles. There are lots of uninvited guests. It's a message pump. You're permitted to be a part of it, and the contract requires that you pass on anything you don't need or (in particular) don't understand. Don't put it your switch. You shouldn't be returning true. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
