Re: Receiving data
[EMAIL PROTECTED] wrote: Can you please tell me when I get -1 and "netErrWouldBlock" .. after receiving the data, does that mean its the end of data? no more data available to read? netErrWouldBlock means the system's network receive buffer is empty for that socket. There might be more data coming or there might not. netErrWouldBlock doesn't indicate that there isn't any more data coming. It just means that if there *is* more to come, it hasn't arrived *yet*. - Logan -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Starting Card Files Into The Default Apps
Hi all! I want to open card files in the "default" application. Here is what I've done so far: - html files open properly in Blazer with "sysAppLaunchCmdGoToURL" and file:///DRIVE/PATH/NAME url. - all other files are handled through "local exchange", but lots of problems arise: 1. The Media app - problems - ignores the request if "ExgPreviewInfoType" struct is defined in the "ExgLocalSocketInfoType" struct that is set in the socket struct; - crashes if the "noAsk" field in the ExgLocalSocketInfoType is "true"; - makes a second copy of the image file (from: "1.jpg" it makes "1[1].jpg"); - ignores "sysAppLaunchCmdGoToURL" (just tried to be sure); 2. RealPlayer - problems: - shows a message "Cannot write to card. Please insert a writable card." and quits. 3. Documents To Go - no problems at all. Properly starts the document (.xls, .doc, etc), does not make secondary copy. Please, advise on any of the issues! Maybe there is a way not to "send" the whole file (with VFSFileRead()/ExgSend() ) but to just point the app to the file! Ready to answer questions or to post the source code! Best, Ilia. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Form Loading Problem
The "c" file code follows. The "rcp" file code comes after that:
/*
* PSEDAT.c
*
* main file for PSEDAT
*
* This wizard-generated code is based on code adapted from the
* stationery files distributed as part of the Palm OS SDK 4.0.
*
* Copyright (c) 1999-2000 Palm, Inc. or its subsidiaries.
* All rights reserved.
*/
#include
#include
#include "PSEDAT.h"
#include "PSEDAT_Rsc.h"
Err SetFieldTextFromStr(FieldPtr field, Char *s, Boolean redraw);
/*
* Entry Points
*/
/*
* Global variables
*/
/*
* Internal Constants
*/
/* Define the minimum OS version we support */
#define ourMinVersionsysMakeROMVersion(3,0,0,sysROMStageDevelopment,0)
#define kPalmOS20Version sysMakeROMVersion(2,0,0,sysROMStageDevelopment,0)
/*
* Internal Functions
*/
/*
* FUNCTION: GetObjectPtr
*
* DESCRIPTION:
*
* This routine returns a pointer to an object in the current form.
*
* PARAMETERS:
*
* formId
* id of the form to display
*
* RETURNED:
* address of object as a void pointer
*/
static void * GetObjectPtr(UInt16 objectID)
{
FormType * frmP;
frmP = FrmGetActiveForm();
return FrmGetObjectPtr(frmP, FrmGetObjectIndex(frmP, objectID));
}
/*
* FUNCTION: SetFieldTextFromStr(FieldPtr field, Char *s, Boolean redraw)
*
* DESCRIPTION: This routine puts text in a screen object.
*
* PARAMETERS:
*
* frm
*
*/
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;
}
/*
* FUNCTION: ClearFieldText
*
* DESCRIPTION: This routine puts text in a screen object.
*
* PARAMETERS:
*
* frm
*
*/
void ClearFieldText(FieldPtr field, Boolean redraw)
{
SetFieldTextFromhandle(field, NULL, redraw);
}
//Yet another function to set the text in a field
void mySetFieldText(FormType *frmP, UInt16 fieldID, Char *st)
{
FieldType*fldP;
MemHandletextH;
Char*textP;
UInt8fldLen=0;
fldP = FrmGetObjectPtr (frmP, FrmGetObjectIndex (frmP, fieldID));
FldFreeMemory(fldP);
FldSetTextHandle (fldP , NULL);
fldLen=FldGetMaxChars(fldP);
textH=MemHandleNew(fldLen+1);
if (textH){
textP=MemHandleLock(textH);
StrNCopy(textP,st,fldLen);
textP[fldLen]=0;
MemHandleUnlock(textH);
FldSetTextHandle (fldP , textH);
}
//optional draw if the form is the current active form
if (frmP==FrmGetActiveForm())
FldDrawField(fldP);
}
/*
* FUNCTION: MainFormInit
*
* DESCRIPTION: This routine initializes the MainForm form.
*
* PARAMETERS:
*
* frm
* pointer to the MainForm form.
*/
static void MainFormInit(FormType *frmP)
{
FieldType *field;
const char *wizardDescription;
UInt16 fieldIndex;
fieldIndex = FrmGetObjectIndex(frmP, MainDescriptionField);
field = (FieldType *)FrmGetObjectPtr(frmP, fieldIndex);
FrmSetFocus(frmP, fieldIndex);
wizardDescription =
"C application\n"
"Creator Code: !!$g\n"
"\n"
"Other SDKs:\n"
;
/* dont stack FldInsert calls, since each one generates a
* fldChangedEvent, and multiple uses can overflow the event queue */
FldInsert(field, wizardDescription, StrLen(wizardDescription));
}
static void TransformerFormInit(FormType *frmP)
{
FieldType *field;
const char *wizardDescription;
UInt16 fieldIndex;
fieldIndex = FrmGetObjectIndex(frmP, kVA);
field = (FieldType *)FrmGetObjectPtr(frmP, fieldIndex);
FrmSetFocus(frmP, fieldIndex);
wizardDescription =
"C application\n"
"Creator Code: !!$g\n"
"\n"
"Other SDKs:\n"
;
/* dont stack FldInsert calls, since each one generates a
* fldChangedEvent, and multiple uses can overflow the event queue */
FldInsert(field, wizardDescription, StrLen(wizardDescription));
}
/*
* FUNCTION: MainFormDoCommand
*
* DESCRIPTION: This routine performs the menu command specified.
*
* PARAMETERS:
*
* command
* menu item id
*/
static Boolean MainFormDoCommand(U
Re: Form Loading Problem
Del Ventruella wrote: The "c" file code follows. The "rcp" file code comes after that: FORM ID TransformerForm AT ( 0 0 160 160 ) NOFRAME MENUID DataEntryMenu BEGIN TITLE "Transformer - PSEDAT" BUTTON "OK" ID XFMROKButton AT (62 137 40 12) LABEL "New Label" ID kVA AT (57 58) END The first thing that stikes me is that you have no field defined on your "TransformerForm" form. You seem to be trying to apply the text to a label object instead of a field object. I'm surprized that you don't get errors, or crashes. Bob -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
How to create menu dynamically?
Hi I want to create menu dynamically, in which i can put some menus depending on conditions. Also i want to chane the caption of one menu frequently. For ex. Current Date. How can i do it? Thanks in advance Regards Amit -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Form Loading Problem
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. 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". 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. 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.) Any guidance would be very much appreciated. Thanks. - Original Message - From: "Robert Moynihan" <[EMAIL PROTECTED]> To: "Palm Developer Forum" Sent: Friday, October 14, 2005 8:17 AM Subject: Re: Form Loading Problem > Del Ventruella wrote: > > >The "c" file code follows. The "rcp" file code comes after that: > > > > > > > >FORM ID TransformerForm AT ( 0 0 160 160 ) > >NOFRAME MENUID DataEntryMenu > >BEGIN > >TITLE "Transformer - PSEDAT" > > BUTTON "OK" ID XFMROKButton AT (62 137 40 12) > > LABEL "New Label" ID kVA AT (57 58) > >END > > > > > The first thing that stikes me is that you have no field defined on your > "TransformerForm" form. You seem to be trying to apply the text to a > label object instead of a field object. I'm surprized that you don't > get errors, or crashes. 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/
Re: How to create menu dynamically?
[EMAIL PROTECTED] wrote: Hi I want to create menu dynamically, in which i can put some menus depending on conditions. Also i want to chane the caption of one menu frequently. For ex. Current Date. How can i do it? You'll probably be wanting to look up the "MenuAddItem()" command in the reference docs. You can add items, and hide/show them. You can't simply go in and edit the contents of the menu items, but you can customize with these commands. Bob -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
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:
GRAFFITISTATEINDICATORat (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/
Re: multiple segments
On Thu, Oct 13, 2005 at 05:23:42PM -, Troy Lokitz wrote: > For some reason, it is crashing when it tries to get an event. It > compiles ok (no coderes errors) but i can't get it to stop crashing. It would help if you provided any errors you received when it crashed. > 1) does a section have to exist in only one header file for only one c >file? No. > 2) do all of the functions within the c file have to be part of the >same section? No. > 3) What are the rules for calling a function from one section (in one >c file) from another in a nother c file Basically, when you declare a function to be in another section, the caller prepares the jump differently then if it thought it was in the same section (i.e., the generated assemler code will be different). So, if the caller's code isn't aware that the function is in a different section, then the compiler isn't going to generate the correct code. The best way to ensure that the compiler knows what section each function is in is: A) Put all of the function declarations in one place and #include that in each .c file. B) Add -Werror-implicit-function-declaration to your compilation flags. This way the compiler will refuse to compile any code that makes function call if the function hasn't been previously declared. If you follow those two basic guidelines then you'll never have your function calls jumping into the wrong section. -- Dave Carrigan Seattle, WA, USA [EMAIL PROTECTED] | http://www.rudedog.org/ UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL-Postfix -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
RE:Compressing records with Lz77
Hi, What about using zlib? Almost every Palm OS user has it and it is free to use AFAIK! I would not use an undocumented API as it can change very very fast! Best regards Tam Hanna http://www.tamoggemon.com Subject: Compressing records with Lz77 From: Trevor MacPhail <[EMAIL PROTECTED]> Date: Wed, 12 Oct 2005 20:03:22 -0700 X-Message-Number: 21 I'm writing an application that is going to be working with a potentialy large database of almost all text and I'd like to compress the records. Is it possible to use PalmOS's Lz77 API for this? And if so, HOW? I can't find any documentation of the functions other than what little there is in the Lz77Mgr.h header file. -- Trevor MacPhail -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Form Loading Problem
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"
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:
> GRAFFITISTATEINDICATORat (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);
> FrmSetActiveFo
Re: Form Loading Problem
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"
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:
> GRAFFITISTATEINDICATORat (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
Re: Compressing records with Lz77
as i look to palmone sdk i see that lz77mgr is not supported on zire handhelds and many others so it isn't good choice my advise is to use zlib instead (and you may also add prcfile to your application so user can install it if he miss it...) Tam Hanna wrote: > Hi, > What about using zlib? Almost every Palm OS user has it and it is free to > use AFAIK! I would not use an undocumented API as it can change very very > fast! > Best regards > Tam Hanna > http://www.tamoggemon.com > > Subject: Compressing records with Lz77 > From: Trevor MacPhail <[EMAIL PROTECTED]> > Date: Wed, 12 Oct 2005 20:03:22 -0700 > X-Message-Number: 21 > > I'm writing an application that is going to be working with a potentialy > large database of almost all text and I'd like to compress the records. > Is it possible to use PalmOS's Lz77 API for this? And if so, HOW? I > can't find any documentation of the functions other than what little > there is in the Lz77Mgr.h header file. > -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
creating a super list - custom list and search
I would like to create a "super list" for my application. I want to use custom draw (as the list is populated from a DB and could be quite long) but I also want to be able to search by entering the first few characters. I thought I could create my own popup box with a custom list or table but I'm not sure how to handle; 1) drawing it over my form, 2) pendown outside the box to return to my form, 3) actions while within the box, e.g. key presses, scrolling etc. Should I use a gadget (not used one before) or a model form? Hope someone can help. Ewen -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
GSM.c, Line: 2236, Serial break condition occured (indicating FW crash)
I tried to find a user support forum, but it looks like there is only one for developers, so I will risk asking here. I have a Cingular Treo 650 with Firmware 01.31 and software Treo650-1.15-CNG and hardware "A." When I connect the treo 650 to my laptop via bluetooth and start bringing home the data, every 50mb or so I will encounter the above error. It is posted spelled incorrectly, as that is how the actual message appears. Searching google gives me a handful of other people who have experienced this, but nothing useful. I am going to venture to say that the error has nothing to do with any installed programs, and has to do with the firmware contained within the broadcom chip. https://gullfoss2.fcc.gov/prod/oet/forms/blobs/retrieve.cgi?attachment_id=483114&native_or_pdf=pdf I am no expert, but since the nature of this problem seems to be even out of Palm's scope, I have about 0 hope of actually getting some help or getting it fixed...but nonetheless would like to know if there is anything I can do to help myself, as these resets are heartbreaking. -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
How to insert text in field problem
I am using the following to try to induce some text to appear in a field on a
form that is not the main form for the application.
This works on the main form. It doesn't work on a form that is subsequently
created through a menu selection from the main form. (The second form does
appear, but the text does not appear when the button is selected on that
non-main form.) The FormInit functions are identical.
static Boolean TransformerFormHandleEvent(EventType * eventP)
{
Boolean handled = false;
FormType * frmP;
switch (eventP->eType)
{
case menuEvent:
return TransformerFormDoCommand(eventP->data.menu.itemID);
case frmOpenEvent:
frmP = FrmGetActiveForm();
FrmDrawForm(frmP);
TransformerFormInit(frmP);
handled = true;
break;
case frmUpdateEvent:
/*
* To do any custom drawing here, first call
* FrmDrawForm(), then do your drawing, and
* then set handled to true.
*/
break;
case ctlSelectEvent:
{
//frmP = FrmGetActiveForm();
if (eventP->data.ctlSelect.controlID == XFMROKButton)
{
/* The "Clear" button was hit. Clear the contents of the field. */
FieldType * field = (FieldType*)GetObjectPtr(kVA);
if (field)
{
FldDelete(field, 0, 0x);
FldDrawField(field);
}
break;
}
if (eventP->data.ctlSelect.controlID == TransTxt)
{
/* The "TransTxt" button was hit. Put a text string in the main field. */
FieldType * field = (FieldType*)GetObjectPtr(kVA);
//FieldType * field =(FieldType*) GetObjectPtr(FrmGetObjectIndex(frmP, kVA));
if (field)
{
Char* pText = (Char*) MemPtrNew(15); // allocate 15 bytes
//FieldType * field;
Boolean redraw;
redraw=true;
// copy kVA into the char ptr
StrCopy(pText, "2000 kVA");
//Put the text in the field
SetFieldTextFromStr(field, pText, redraw);
handled=true;
}
break;
}
break;
}
}
return handled;
}
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
Re: creating a super list - custom list and search
[EMAIL PROTECTED] wrote: I would like to create a "super list" for my application. I want to use custom draw (as the list is populated from a DB and could be quite long) but I also want to be able to search by entering the first few characters. Ah, can't do both of those with the built-in list IIRC. Once you set the callback for custom drawing, searching by the first few characters gets disabled (because the system rightly assumes it can't be sure what your list items contain). I thought I could create my own popup box with a custom list or table but I'm not sure how to handle; 1) drawing it over my form, 2) pendown outside the box to return to my form, 3) actions while within the box, e.g. key presses, scrolling etc. The easiest thing would probably be to just draw it on top of whatever is already there. If your list is going to be relatively small, you could use WinSaveBits() and WinRestoreBits() to put things back like they were when your list goes away. If you don't think the device will have enough memory to save that big a portion of the screen, you can just do FrmUpdateForm() after your custom popup list is dismissed. (Or just directly call whatever function you call in response to FrmUpdateForm().) As for how to handle the events, if you go this route, you just have a flag in your form that tells whether the list is active. In your form's event handler, if the flag shows that the list is active, avoid the normal handling and pass all events to an event handler for the custom popup list you've created. In the custom popup list's handler, any pen tap outside the list's rectangle will cause the list to dismiss, and other events (keystrokes and pen taps) will affect the state of the list however you want. You also need to correctly handle the case where the form is closed while the popup is open (freeing any memory associated with it, etc.) in case someone presses the datebook button while your custom popup is active. I use this method for a simple custom popup (not a super list; I just needed it to look pretty), and it seems to work fine. One issue I haven't solved with this method (since I haven't needed to) is having such a list inside a modal dialog. You want the system to be able to give you a default button press in case it needs to dismiss your dialog to close your app, but if you are diverting all events to a different handler, that won't happen. You could probably solve this by having the popup handler detect such an event and first dismiss itself, then call the regular form event handler to handle it as if the list event handler hadn't intercepted it. - Logan -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: How to insert text in field problem
Just in case anyone was considering a response to this.
I used FrmGotoForm(), instead of FrmInitForm(), to call the second form, and
the emulator permitted me to assign text to a field on the non-main form.
FrmInitForm() continued to work to induce the "about" form to appear when
called from the main form.
FrmGotoForm() didn't work to produce the about form from either the main or
other form,
probably because I haven't written an about form handler (yet). As a
result, I still can not
go to the "about" form from the non-main form. It seems odd that I don't
need a
form handler from the main form, but seem to need one from
a non-main form to induce the "about" form to appear on the screen.
- Original Message -
From: "Del Ventruella" <[EMAIL PROTECTED]>
To: "Palm Developer Forum"
Sent: Friday, October 14, 2005 3:20 PM
Subject: How to insert text in field problem
> I am using the following to try to induce some text to appear in a field
on a form that is not the main form for the application.
>
> This works on the main form. It doesn't work on a form that is
subsequently created through a menu selection from the main form. (The
second form does appear, but the text does not appear when the button is
selected on that non-main form.) The FormInit functions are identical.
>
> static Boolean TransformerFormHandleEvent(EventType * eventP)
> {
> Boolean handled = false;
> FormType * frmP;
>
> switch (eventP->eType)
> {
> case menuEvent:
> return TransformerFormDoCommand(eventP->data.menu.itemID);
>
> case frmOpenEvent:
> frmP = FrmGetActiveForm();
> FrmDrawForm(frmP);
> TransformerFormInit(frmP);
> handled = true;
> break;
>
> case frmUpdateEvent:
> /*
> * To do any custom drawing here, first call
> * FrmDrawForm(), then do your drawing, and
> * then set handled to true.
> */
> break;
>
> case ctlSelectEvent:
> {
> //frmP = FrmGetActiveForm();
> if (eventP->data.ctlSelect.controlID == XFMROKButton)
> {
> /* The "Clear" button was hit. Clear the contents of the field. */
> FieldType * field = (FieldType*)GetObjectPtr(kVA);
> if (field)
> {
> FldDelete(field, 0, 0x);
> FldDrawField(field);
> }
> break;
> }
> if (eventP->data.ctlSelect.controlID == TransTxt)
> {
> /* The "TransTxt" button was hit. Put a text string in the main field. */
> FieldType * field = (FieldType*)GetObjectPtr(kVA);
>
> //FieldType * field =(FieldType*) GetObjectPtr(FrmGetObjectIndex(frmP,
kVA));
> if (field)
> {
> Char* pText = (Char*) MemPtrNew(15); // allocate 15 bytes
> //FieldType * field;
> Boolean redraw;
> redraw=true;
> // copy kVA into the char ptr
> StrCopy(pText, "2000 kVA");
> //Put the text in the field
> SetFieldTextFromStr(field, pText, redraw);
> handled=true;
> }
> break;
> }
> break;
> }
> }
> return handled;
> }
>
> --
> 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/
Re: How to insert text in field problem
Del Ventruella wrote: Just in case anyone was considering a response to this. I used FrmGotoForm(), instead of FrmInitForm(), to call the second form, and the emulator permitted me to assign text to a field on the non-main form. FrmInitForm() continued to work to induce the "about" form to appear when called from the main form. FrmGotoForm() didn't work to produce the about form from either the main or other form, probably because I haven't written an about form handler (yet). As a result, I still can not go to the "about" form from the non-main form. It seems odd that I don't need a form handler from the main form, but seem to need one from a non-main form to induce the "about" form to appear on the screen. I tried looking at your code, and the formatting is messed up so it's hard to tell exactly what you're doing, but it seems like the order you're doing things is really, really odd. Have you tried just doing this? FormPtr frmptr = FrmInitForm (AboutForm); FrmDoDialog (frmptr); FrmDeleteForm (frmptr); Do that in response to a button in your main form. If you need to set some text in a field, do it after you call FrmInitForm() but before FrmDoDialog(). - Logan -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Receiving data
Hi All, thanks a lot, it helped me a lot. .. KiraN Puranik -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
