"Matt Graham" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]Stephen Klein wrote:
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.
Thanks for the info, good to know for the next time I'm doing field work.
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?!)
I don't think this would be as much trouble as you're imagining. Delete can be done pretty easily. Just add a function to handle keyDown events on the fields you want. Then return true to the keyDown and the OS won't do anything funny w/ your memory.
A new char can be easily appended, and the MemHandle size increased if
necessary. Delete is done w/ just a call to FldGetSelection. If text is
selected, copy down from any chars after the selection. If no selection, just remove the character before the cursor.
Again tho, if it's not worth it, it's not worth it.
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
