Is recPtr in DmWrite() a valid pointer?
That said, I found some old mail from Ken Krugler regarding FldGetTextPtr():
>>>
If you've got a typical editable field, then the pointer returned by
FldGetTextPtr should be valid until:
a. You make another call to the field code. Some of the Field APIs
would seem safe to call, but given the dynamic nature of the rom code,
you're better off not relying on the pointer staying valid.
b. You make a call to something that in turn calls a field routine.
For example, the form code will call the field code to dispose of the
handle when the form is being tossed.
c. The field's text handle gets munged by you or some other routine
which knows about it. Obviously if you mess with the handle then all bets
are off.
Note that if the field is empty, then the call to FldGetTextPtr can return
null if the text handle never had to be allocated.
<<<
Michael Yam
Y Technology, Inc.
[EMAIL PROTECTED]
-----Original Message-----
From: Gabe Dalbec <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, May 07, 1999 1:36 AM
Subject: FldGetTextPtr - not a good pointer?
I am seeing some strange results from the Emulator when I use
FldGetTextPtr. The following code snip shows this:
{
CharPtr fldVal;
Char saveVal[100];
fldVal = FldGetTextPtr(fieldP);
if(fldVal)
{
int len = StrLen(fldVal);
if(len < 100)
{
StrCopy(saveVal, fldVal);
DmWrite(recPtr, 0, fldVal, len);
}
}
}
When this runs, the Emulator reports an error on the DmWrite, saying
that I "have just read directly from memory manager data structures".
Why does it report this on the DmWrite but not on the StrLen or the
ScrCopy, both of which access the same fldVal. If I change the code to
use FldGetTextHandle and MemHandleLock instead of going straight to the
pointer with FldGetTextPtr, then it works fine, no complaints from the
emulator. Either way runs fine on the device.
Is this a bug in the emulator or maybe the OS, or am I missing
something?
Thanks,
-Gabe
Palm Creations
