no, CtlSetLabel does not draw the object unless it was not already drawn.
however, clearly the "SetFieldTextFromStr" function is home grown. the
source for that function is not given, but would anyone like to place bets
that near the end of that function is a call for FldDrawField...? :-)
----- Original Message -----
From: William F. Weiher III <[EMAIL PROTECTED]>
To: Palm Developer Forum <[EMAIL PROTECTED]>
Sent: Wednesday, February 09, 2000 8:15 AM
Subject: RE: Please Help with "Field Ghosting Prob"
> Some of the API functions actually draw to the screen (such as
CtlSetLabel)
> actually draw to the screen. You must not call any of these functions
before
> the form is drawn. Some of the functions (such as TblSetRowId) just modify
> the memory structure of the object. In this case, that data will be used
> when FrmDrawForm actually draws the table so it should be called before
> FrmDrawForm. The documentation is not always perfectly clear about which
is
> which. If the documentation says anything about redrawing the object, do
not
> call it before FrmDrawForm. In some cases you might have to look at the
> actual OS code to be certain.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of John R.
> Violette
> Sent: Tuesday, February 08, 2000 19:54
> To: Palm Developer Forum
> Subject: Re: Please Help with "Field Ghosting Prob"
>
> See also the post titled "Modal Form" on pilot.programmer for what the
> problem was and more code. It is solved now, but a small mystery remains
in
> my mind (see below about the table). Here is a summary:
>
> That indeed was it. I was doing this:
>
> case frmOpenEvent:
> frmP = FrmGetActiveForm();
> versionStrP = MemHandleLock (DmGetResource ('tver', VersionID));
> SetFieldTextFromStr(AboutFormVersionField, versionStrP);
> urlStrP = MemHandleLock (DmGetResource ('tSTR',
> AboutFormWebURLString));
> SetFieldTextFromStr(AboutFormWebURLField, urlStrP);
>
> MemPtrUnlock(versionStrP);
> MemPtrUnlock(urlStrP);
> FrmDrawForm(frmP);
> handled = true;
> break;
>
> when I should have been doing this:
>
> case frmOpenEvent:
> frmP = FrmGetActiveForm();
> FrmDrawForm(frmP);
> versionStrP = MemHandleLock (DmGetResource ('tver', VersionID));
> SetFieldTextFromStr(AboutFormVersionField, versionStrP);
> urlStrP = MemHandleLock (DmGetResource ('tSTR',
> AboutFormWebURLString));
> SetFieldTextFromStr(AboutFormWebURLField, urlStrP);
>
> MemPtrUnlock(versionStrP);
> MemPtrUnlock(urlStrP);
> handled = true;
> break;
>
> throughout every form in my app which caused this "Field Ghosting" to pile
> up when switching forms or to stay on the form depending on how I
displayed
> it. Thanks a bunch. The reason I had switched to doing it that was was
that
> I have a table with custom drawing and in it I still have to do this or
else
> the table comes up empty:
>
> case frmOpenEvent:
>
> file://FrmCustomAlert(ErrorAlert, "Received open event", NULL, NULL);
> // must do before draw form or else comes up empty table
> InitializeClientListTable();
> FrmDrawForm( frmP);
> handled = true;
> break;
>
> So why in this case do I HAVE TO draw to the form first which is breaking
> the rule???? I know, I know so that my table will show up, but why is it
> different in this case and why do only FIELDS seem to ghost???
>
> Although the above doesn't leave garbage from the table when I dismiss
that
> form. I find the user interface stuff more difficult than the database
> stuff.
>
> Thanks to all who provided info....
> Later...
>
>
>
>
>
> Thanks to all
> John R. Violette <[EMAIL PROTECTED]> wrote in message
> news:1358@palm-dev-forum...
> >
> > See example and description of problem here...
> >
> > http://free.prohosting.com/~jpdrp/prob.htm
> >
> >
> >
> >
> >
> >
>
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
> please see http://www.palm.com/devzone/mailinglists.html
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
