When I attempt to use the field changing routine, I get the attached screen output, which places the application screen name to the right of the field whose text I am attempting to alter.
----- 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/
screen.bmp
Description: Windows bitmap
