Mike, >I wonder why they are so tricky? It seems so straightforward!
The OS builds structures in dynamic memory for each form object. For labels, the amount of space reserved is based on the original text assigned. If you later replace that with a shorter string, there is no problem. If you replace it with a longer string, it runs past the space formerly allocated for it and corrupts the adjacent form object structure leading to "unpredictable results". >Ugh. I might just do what you said. I just hate to give up on something >that seems like it should work just fine. I hate not having an explanation! My guess is you still had problems after trying a seemingly shorter string because StrPrintF() may have altered more room than alloted for the original string as part of its processing. I don't know for sure how StrPrintF() works, but if you attempt something like StrIToA() you must allocate more room than just the number of digits necessary for your value may suggest. If you don't use maxStrIToALen you can run into a similar problem running beyond the bounds you defined. Instead of StrPrintF(), try using StrCopy() to set a shorter string and I think you'll see shorter strings work, while longer strings (than the original label text) corrupt the adjacent form object. Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
