I appreciate your input, but I have come to some conclusions, which may be
erroneous, but seem to fit what I'm running into.
1. The Graffiti state indicator can be added in PILRC by selecting what
looks like an innocuous up arrowed control symbol.
(The article I read was right. You add it and forget about it.)
2. Calling forms seems to be reserved for the main form. I can't use the
same code to call forms from other forms that are subsequently opened. I
don't
know if this is part of the OS to prevent large programs from being
attempted. I may be wrong, but it certainly fits the behavior.
-----------------------------------
My event handling routine does do what you suggest:
static Boolean AppHandleEvent(EventType * eventP)
{
UInt16 formId;
FormType * frmP;
if (eventP->eType == frmLoadEvent)
{
/* Load the form resource. */
formId = eventP->data.frmLoad.formID;
frmP = FrmInitForm(formId);
FrmSetActiveForm(frmP);
/*
* Set the event handler for the form. The handler of the
* currently active form is called by FrmHandleEvent each
* time is receives an event.
*/
switch (formId)
{
case MainForm:
FrmSetEventHandler(frmP, MainFormHandleEvent);
break;
case TransformerForm:
FrmSetEventHandler(frmP, TransformerFormHandleEvent);
return true;
break;
}
return true;
}
return false;
}
-----------------------------
The field text changing routine that I am using also does redraw the field
if the
variable "redraw" is set to true, which it is in my code:
Err SetFieldTextFromStr(FieldPtr field, Char *s, Boolean redraw)
{
MemHandle h;
h = FldGetTextHandle(field);
if (h)
{
Err err;
FldSetTextHandle(field, NULL);
err= MemHandleResize(h,StrLen(s)+1);
if (err != errNone)
{
FldSetTextHandle(field, h); //Restore handle.
return err;
}
}
else
{
h = MemHandleNew(StrLen(s) + 1);
if (!h)
return memErrNotEnoughSpace;
}
//At this point, we have a handle of the correct size.
//Copy the string to the locked handle.
StrCopy((Char*) MemHandleLock(h), s);
//Unlock the string handle.
MemHandleUnlock(h);
FldSetTextHandle(field, h);
if (redraw)
FldDrawField(field);
return errNone;
}
----- Original Message -----
From: "Robert Moynihan" <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[email protected]>
Sent: Friday, October 14, 2005 9:25 AM
Subject: Re: Form Loading Problem
> Del Ventruella wrote:
>
> >Thank you. (I somehow thought that was a field, but you were, of course,
> >correct.) The compiler now requires a Graffiti state indicator for this
> >editable field. I did read an article a couple of years ago on Palm
> >programming that indicated that this was required if one wished to enable
> >pen input to a field. It was supposed to be a simple matter to add it.
I
> >just can't recall how the article stated that one did that.
> >
> No, you don't need the graffiti state indicator, but it's good practice,
> and you'll get the error message at compile time if you don't. There
> might be a way to suppress that message, but you could add some code
> like this just after the field definition in the rcp file to add the
> indicator:
> GRAFFITISTATEINDICATOR at (145 prevtop)
>
> > In its current
> >state, if I click on the kVA FIELD, it now puts a graphic tab ending in
mcp
> >in the field. It won't accept the character input I had specified of
> >"2000".
> >
> >
> Remember that it you change the contents of a field then you need to
> 'draw' is afterwards to see the new text. The FrmDoDialog() or
> FrmDraw() commands should do this for you, but if you have already drawn
> the form then you need to use FldDrawField(). When you define the field
> make sure that you give it sufficient visible characters. Start with a
> large number so that you are sure to have enough room, then pare down
> from there once it's working.
>
> >I also have added handlers for the "about" form. PILRC didn't seem to
need
> >them to put the about form on the screen from the main form, but I added
> >them nevertheless.
> >
> If you are still using FrmDoDialog then the default dialog handler will
> be used unless you specifically declare that your custom handler should
> be used instead.
>
> > I am still not getting the "about" form when I click on
> >the menu item. (I tried the form go to form code, but I believe that
> >probably is intended if one already has a non-modal form open and simply
> >wants it to be placed on top of the visible stack of forms. It didn't
> >achieve the desired end.)
> >
> >
> FrmGotoForm() will load the form, and the form will be deleted when you
> FrmGotoForm() to some other form. When you use FrmGotoForm() you will
> need to respond to the FrmLoadEvent, so that you can tell the system
> which form handler to use for that form. In your event loop you could
> respond like so:
>
> if (event->eType == frmLoadEvent){
> formID = event->data.frmLoad.formID;
> frmP = FrmInitForm(formID);
> FrmSetActiveForm(frmP);
>
> switch (formID)
> {
> case mainform:
> FrmSetEventHandler(frmP, MainFormHandler);
> return true;
> case otherForm:
> ......
> case ...and so on
> }
>
> Bob
>
> --
> For information on using the PalmSource Developer Forums, or to
unsubscribe, please see http://www.palmos.com/dev/support/forums/
>
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
