The example given here is not my real code. It does something similar, but
don't worry about pointing out minor bugs in the code given here. The
point is that using FldGetTextPtr(fieldP) and then using string operations
on the text pointer work, but using DmWrite on the same pointer does
not work - unless I use FldGetTextHandle / MemHandleLock. Interesting
what you are saying about the handle not always being correct. Maybe
what I should do in my code is copy out of the pointer from FldGetTextPtr
and then pass the copy of the string to the DmWrite call?
Thanks,
-Gabe
Palm Creations
> At 10:38 PM -0700 5/6/99, Gabe Dalbec wrote:
> >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);
> > }
> > }
> >}
>
> I'm glad you were able to solve your memory problem. But I'm puzzled about
> the solution. FldGetTextHandle should generally return a handle to the
> same object that FldGetTextPtr returns. If that's not the case, there's
> something else seriously wrong.
>
> In general, FldGetTextHandle/MemHandleLock is not a replacement for
> FldGetTextPtr, because the actual text may start at an offset into the
> chunk, and so the raw pointer to the chunk won't represent the actual text
> being edited. Since your app controls the field, you can probably
> eliminate this case.
>
> I'm puzzled by why you have saveVal in the above code -- you're copying the
> text out of the field to a stack variable, but then never using it?
>
> Also, you might have some trailing '\0' problems in the above code. You
> don't appear to write the trailing null to the data manager record, which
> might later cause other users of the string to get bad data. Remember:
> StrLen returns the number of bytes in the string EXCLUDING the trailing
> null. (I say bytes because if the string is international, byte count and
> character count may differ.)
>
