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.)
--Bob
