"Matt Graham" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Stephen Klein wrote:
> > I'm working on an application that uses an editable text 'Field' to
> > hold text that the user can edit. The user could indicate that this
> > data is private (and should be encrypted).
> >
> > My question is - while the user is editing the text in this field,
> > the field (behind the scenes) may be resizing the memory buffer that
> > holds the text - possibly copying it into a larger free block when it
> > runs out of contiguous memory to support continued growth - or
> > possibly releasing part of the block back to the heap after a large
> > delete. Either way, the heap could end up storing fragments of the
> > private data in unallocated memory...
>
> Fields have a max chars property that the ui uses to stop input at a
> certain size. I'm not positive about this, but I'm pretty sure that the
> field's handle starts null and then is allocated to the full maxchars
> size + 1 when the first char is entered. Then it shouldn't need to be
> reallocated b/c the max chars property will limit the user input at the
> already allocated size. That's the beviour I've seen anyway.
>
I just tried a quick experiment - did a FldGetTextHandle() followed by
MemHandleSize() and got a size that matched the size of the data that the
field was initialized with (which was much less than the max chars
property) - so I'm guessing that the behaviour you saw was on an earlier
version of the os - it looks from what I'm seeing like it's been enhanced to
do dynamic resizing.
>
> > From a purist's point of view - is there a good way to clean all this
> > up before control passes to some other application? So far, I
> > haven't thought of one, since I don't see a way for my application to
> > put hooks into the interactions between the field control and the
> > memory manager(!).
>
> Now, if you want to kill that memory, you could zero it when you close
> the form. Something like this function (never been compiled)
>
> void zero_field( FieldType *f )
> {
> FieldType *f = your_field();
> MemHandle h = FldGetTextHandle( f );
> FldSetTextHandle( f, 0 );
> void *p = MemHandleLock( h );
> MemSet( p, MemHandleSize( h ), 0 );
> MemHandleFree( h );
> }
>
>
Thanks! That's probably the best that is actually feasible... (at least it
covers cases where there was no or little editing done).
>
> > From a practical standpoint, I'm not sure how *real* the need is to
> > develop an absolutely bulletproof solution - however, it's a puzzle,
> > and I wondered if any of the experts in this forum would have some
> > comments.
>
> If you really want to be hard core about it, you can catch the keyDown
> events and check for focus on the field. Then you can handle the memory
> management yourself and be sure that important memory is not getting
> lost in the heap.
>
Interesting idea(!) - I think it could work, particularly for predicting
(and sidestepping) an expansion of the buffer. I would also need to clobber
data before it got deleted because, on a really big delete, the field could
shrink the buffer and leave some of this data in unallocated space (I think
that's when we get the warning messages about an operation that can't be
undone) - but even that might not always work because the high end of the
buffer is what would get returned to the heap, and it could include some
data that wasn't deleted (but that just got copied down toward the beginning
of the buffer). Argggh! Still, it might be do-able, but I'd need to
implement delete operations myself too (because how can you know when the
field will decide that enough has been deleted that it's time to shrink?)!
All told, this looks like more touble that I want to go to right at the
moment! It would be so easy for this problem to be solved by the o.s. -
say, add a Private attribute to a Field, then let an enhanced Field object
and maybe an enhanced memory manager take care of it :-). (any Palm O.S.
implementers reading?!)
Thanks,
Stephen
> matt
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
