Yeah, sometimes I get nailed with field handles.
Let's say you want a "SetFieldTextTo( someFieldID, pNewString)" kind of
function... follow the code below, and notice the nullification of the
pMyField's handle in the instance where a MemHandleResize is performed.
hFieldText = FldGetTexHandle( pMyField );
if ( !hFieldText )
{
// This one is easy...
hFieldText = MemHandleNew( nSizeOfNewString );
}
else
{
// Need to TRY and resize existing handle:
ULong curSize = MemHandleSize( hFieldText );
if ( curSize < nSizeOfNewString )
{
// MUST nullify handle first:
FldSetTextHandle( pMyField, NULL );
MemHandleResize( hFieldText, nSizeOfNewString);
}
}
Bottom line -- if you're playing with a field's handle, the OS keeps it
locked down. So even when you FldGetTextHandle, its lock count is already 1
so don't even think about doing anything sneaky with it, like trying to free
it and set the field to contain another handle or whatever. Or in this
case, trying to resize it.
That one always gets me.
-Jeff
> -----Original Message-----
> From: Jon Baer [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, November 14, 1999 4:24 PM
> To: [EMAIL PROTECTED]
> Subject: Chunk-Underlocked
>
>
>
> Could someone please post some common reasons for getting
> fatal errors regarding
> "chuck-underlocking"?
>
> Thanks.
>
> - Jon
>
>
>
