In article <38736@palm-dev-forum>, "Ben Combee" <[EMAIL PROTECTED]> wrote:
> "Remo Hofer" <[EMAIL PROTECTED]> wrote in message
> news:38660@palm-dev-forum...
> >
> > Could you please comment the following function:
> >
> > void UpdateControl(FormPtr f, UInt16 id, Char * s) {
> > ControlType *ctl;
> > Char *label;
> >
> > ctl = FrmGetObjectPtr(f, FrmGetObjectIndex(f, id));
> > label = (Char *) CtlGetLabel(ctl);
> > StrCopy(label, s);
> > CtlSetLabel(ctl, label);
> > }
> >
> > It does update the label of a control (selector, popup, button) by copying
> > the new string to the old location (similar to FrmCopyLabel with labels).
> > Of course the new string must not be longer than the old one. But are
> > there any other problems? Perhaps with the direction PalmOS 5 will go? The
> > function assumes that the memory location of the old label is writeable.
> > Will this assumption still be correct for PalmOS 5?
>
> Hmmm... this technique seems to be what CtlCopyLabel would be if it were
> implemented. The biggest issue I'd have with this is that it will fail if
> the control's label has been changed to point to a read-only string, such as
> a PC-relative string in the data segment or a string in a locked database
> record. Your assuming that the string returned is going to be in a writable
> area of memory, which isn't necessarily true.
You're absolutely right. I didn't think of the case where the "original"
(at FrmInitForm time) label pointer has allready been changed. I use this
technique only to overwrite control labels in form memory, which are
initialized to long enough place holders. But is the assumption that this
form memory is writeable reasonable? Even for PalmOS 5?
--
Remo Hofer <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Cable/5206/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
