Dear sir please remove my name from your mailing list than you
----- Original Message -----
From: Palm Developers Forum List <[EMAIL PROTECTED]>
To: Palm Developers Forum List <[EMAIL PROTECTED]>
Sent: Monday, January 17, 2000 8:57 AM
Subject: Palm Dev Forum Digest 1/16/00
> -> RE: OS 3.5 and FrmAlert saving bits behind
> by "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> -> Re: Prc-tools-0.5.1b3 and Palm SDK 3.5, Can they coexist?
> by Aaron Ardiri <[EMAIL PROTECTED]>
> -> RE: Palm OS 3.5 color levels
> by "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> -> RE: PopTriggers & OS 3.5
> by "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> -> Re: OS 3.5 and FrmAlert saving bits behind
> by Keith Wolcott <[EMAIL PROTECTED]>
> -> AppPrefs (and DB) after HotSync - broken?!
> by Danko Radic <[EMAIL PROTECTED]>
> -> Re: Debug nub
> by "Brian O'Grady" <[EMAIL PROTECTED]>
> -> Re: Debug nub followup
> by "Brian O'Grady" <[EMAIL PROTECTED]>
> -> Emulating Palm IIIx
> by [EMAIL PROTECTED]
> -> SelectDay error.
> by Qun Wang <[EMAIL PROTECTED]>
> -> Re: Emulating Palm IIIx
> by "LeGrand Decius" <[EMAIL PROTECTED]>
> -> Re: Emulating Palm IIIx
> by [EMAIL PROTECTED]
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 01:16:34 -0800
> From: "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> Subject: RE: OS 3.5 and FrmAlert saving bits behind
>
> > From: Keith Wolcott [mailto:[EMAIL PROTECTED]]
> > I finally got around to testing my app with the 3.5 debug ROM
> > I have Alert forms, CustomAlert forms and other forms that
> > are all set as usable, modal, and save bits behind.
> >
> > When any one of the forms above is opened and then disposed
> > of on the mainForm, some of the bits behind are not restored.
> > Am I missing something obvious, or is this a bug in OS 3.5?
>
> It's a debug feature of the 3.5 debug ROM, and it just did its job for
you.
> It deliberately doesn't restore saved bits behind dialogs and alerts.
> Instead it just sends a frmUpdate event to your main form, which you must
> handle if you have any custom drawn items (such as the line in your app).
> By default the OS handles frmUpdate by redrawing all the standard form
> objects but doesn't know to redraw your custom line.
>
> This feature was added because normally you don't get the case where the
> background bits can't be saved (due to insufficient memory) but it does
> happen sometimes, usually to end users. Therefore many apps don't handle
it
> properly. And in 3.5, this situation can happen more often because color
or
> gray scale bitmaps consume more memory than black-and-white ones.
>
> - -slj-
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 01:20:30 -0800
> From: Aaron Ardiri <[EMAIL PROTECTED]>
> Subject: Re: Prc-tools-0.5.1b3 and Palm SDK 3.5, Can they coexist?
>
> > you do realize John works for Palm, don't you?
>
> :))
>
> > i'm surprised you would make such a silly suggestion as naming the OS
3.5
> > SDK "OS 3.5.1 SDK" since that would be even worse than the problem you
seem
> > to think you're solving. you do realize that OS 3.5 doesn't exist yet?
and
> > that OS 3.5.1 exists even less? do you really want to use the "OS
3.5.28.c
> > SDK" to develop for OS 3.5?
> >
> > i mean really. it sends Palm the wrong message if we scream at them to
> > release pre-alpha versions of the OS SDK, and then we give them a hard
time
> > for making us actually have to look at a date stamp to differentiate the
> > between pre-alpha versions.
> >
> > or did you reply to that one without any idea what the message was
talking
> > about? (Bad Replier? Bad?).
>
> since 3.5 has not been officially released.. Palm can do whatever they
> want to the API's :P from what i have seen.. small things here and there
> are changing over the "months".. :)
>
> does anyone have a link for downloading a gcc/3.5 bundle on the web?
>
> az.
> - --
> Aaron Ardiri
> Java Certified Programmer http://www.hig.se/~ardiri/
> University-College i Gavle mailto:[EMAIL PROTECTED]
> SE 801 76 Gavle SWEDEN
> Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
> Mob: +46 70 656 1143 A/H: +46 26 10 16 11
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 02:17:55 -0800
> From: "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> Subject: RE: Palm OS 3.5 color levels
>
> > From: Bill Goodman [mailto:[EMAIL PROTECTED]]
> > Is there a way for users to change the depth of the display
> > or can it only be changed programmatically?
>
> Do you mean a setting that would apply to all apps on the device, and
which
> the user could change in a Prefs panel? The answer appears to be yes.
Look
> in <SystemMgr.h> for sysFtrNumDisplayDepth. This is a feature that
defines
> the default depth that will be used for all applications (until the next
> reset). So you could write a simple Prefs panel to let the user change
it.
> (There isn't any such UI supplied with 3.5 itself.)
>
> (I don't think this is documented, so beware, yada yada...)
>
> > Is it reasonable to assume
>
> Almost certainly not, even without finishing the sentence. :-)
>
> > that the new color devices will
> > always be in 8-bit mode and current devices will always be
> > in 1-bit mode unless your application purposely sets
> > the display to a different color depth?
>
> Given the above, that's probably not safe. I tested my 3.5 IIIx in 4-bit
> mode (by poking the feature given above). Everything worked fine, and the
> built-in apps even have grayscale Launcher icons. I switched back to
1-bit
> mode because everything got slower, and because the Launcher icons are the
> only part of the system that take advantage of the gray. There UI color
> scheme seems to be the exact same as 1-bit, using only black and white.
>
> Question for Palm: will the UI color schemes for 2- and 4-bit modes use
any
> grays, such as for field text highlighting? (Not that I'd want it; my app
> got painfully slow in 4-bit mode at 16MHz.)
>
> - -slj-
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 02:48:03 -0800
> From: "Scott Johnson (WA)" <[EMAIL PROTECTED]>
> Subject: RE: PopTriggers & OS 3.5
>
> > From: Andrew Ball [mailto:[EMAIL PROTECTED]]
> > So now that we've figured out that I'm doing this the wrong
> > way, what would you suggest as the "normal" solution?
> > Something more like (which is what's currently working for me):
> >
> > pTriggerLabel = LstGetSelectionText (lst, ... );
> > CtlSetLabel (ctl, pTriggerLabel);
>
> But this is exactly what the OS does by default if you don't return true
> from your popSelect handler. So none of this is needed. Try removing it
> and see if it still works. And see the OS source.
>
> > and not worry about allocating memory for anything?
> > Or allocate a buffer [...] as a global?
>
> The default behavior is all you need, as long as the list contains static
> strings that won't change while the form is loaded. That's why it's safe
to
> get a pointer to a string inside the list and give it to the trigger. The
> OS default behavior assumes this case.
>
> But if you get fancy and change the string list in the list object later
> (via LstSetListChoices) or if you don't have strings in the list at all
> (using a draw callback) -- then you need to override the default trigger
> setting behavior. Then you'd need to allocate a heap buffer, or just have
a
> static one, or (my suggestion) implement the whole form as a C++ class and
> make the text buffer a data member of the class, to avoid polluting global
> space.
>
> - -slj-
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 04:40:43 -0800
> From: Keith Wolcott <[EMAIL PROTECTED]>
> Subject: Re: OS 3.5 and FrmAlert saving bits behind
>
> Thank you Scott. I will handle the frmUpdate.
>
> Keith
>
> "Scott Johnson (WA)" wrote:
>
> > It's a debug feature of the 3.5 debug ROM, and it just did its job for
you.
> > It deliberately doesn't restore saved bits behind dialogs and alerts.
> > Instead it just sends a frmUpdate event to your main form, which you
must
> > handle if you have any custom drawn items (such as the line in your
app).
> > By default the OS handles frmUpdate by redrawing all the standard form
> > objects but doesn't know to redraw your custom line.
> >
> > This feature was added because normally you don't get the case where the
> > background bits can't be saved (due to insufficient memory) but it does
> > happen sometimes, usually to end users. Therefore many apps don't
handle it
> > properly. And in 3.5, this situation can happen more often because
color or
> > gray scale bitmaps consume more memory than black-and-white ones.
> >
> > -slj-
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 08:42:36 -0800
> From: Danko Radic <[EMAIL PROTECTED]>
> Subject: AppPrefs (and DB) after HotSync - broken?!
>
> (PalmOS 3.0)
> My app creates DB where it stores AppPreferences (with rest of the data).
> When I exit app and start it again, it works well (prefs are loaded
> correctly). Then I backup DB via HotSync onto desktop, delete original DB
> on Palm, and install .pdb file (the same DB) back onto Palm again via
> HotSync.
> DB *looks* the same (it has equal num of records and the size is the same)
> as original DB, but when I start my app it doesn't read AppPreferences
> correctly (I think it's all set to zero). Then even more, when I exit my
> app, an error occurs "DataMgr.c, Line: 6503, Index out of range" and only
> reset can help. After reset my DB has twice more records than it should
> have.
>
> Please help, how to backup DB and then install it back properly?
>
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 16:04:48 -0800
> From: "Brian O'Grady" <[EMAIL PROTECTED]>
> Subject: Re: Debug nub
>
> Thank You Roger, that did the trick.
> Brian
>
>
> - ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, January 15, 2000 7:33 PM
> Subject: Re: Debug nub
>
>
> >
> >
> > >Now I get a error stating my program has "just written directly to
memory
> > >manager data" . This occurs when ever I do something like this
> > >
> > > strStartTime = MemPtrNew(StrLen(recordP->StartTime)) ;
> > > StrCopy(strStartTime, recordP->StartTime);
> >
> > Try using
> >
> > strStartTime = MemPtrNew(StrLen(recordP->StartTime) + 1) ;
> >
> > to account for the string being null terminated by StrCopy.
> >
> >
> > -Roger Flores
> >
> >
> >
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 18:36:28 -0800
> From: "Brian O'Grady" <[EMAIL PROTECTED]>
> Subject: Re: Debug nub followup
>
> Roger,
>
> I have gotten the past the Mem. error when using StrCopy() just to reach
> "... just read directly from an unallocated chunk of memory" when using
> FrmDrawForm(frmP);. This only happens after attempting to draw a form that
> was draw previously. This example occurs after leaving my Main form to my
> Info from then selecting a done button to return to Main. Then I get the
> error. If I click Debug my form appears correctly on the POSE and in the
> Stack window the debugger stopped on StrLen which is under
CtrlDrawControl
> and FrmDrawForm. This code does work on my HH and it worked on the
previous
> version of POSE so I have only gotten this error since changing the POSE.
> Any suggestions as to what I may have to change? Thank You
>
>
> Brian
>
> case ctlSelectEvent:
> if (eventP->data.ctlSelect.controlID == InfoDoneButton)
>
>
> FrmReturnToForm(MainForm);
> frmP = FrmGetActiveForm();
>
> FrmDrawForm(frmP); ******* Get Error Here *******
>
> SetPopLabel(eventP,frmP);
> WinDrawLine(5,135,150,135);
> }
>
> - ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, January 15, 2000 7:33 PM
> Subject: Re: Debug nub
>
>
> >
> >
> > >Now I get a error stating my program has "just written directly to
memory
> > >manager data" . This occurs when ever I do something like this
> > >
> > > strStartTime = MemPtrNew(StrLen(recordP->StartTime)) ;
> > > StrCopy(strStartTime, recordP->StartTime);
> >
> > Try using
> >
> > strStartTime = MemPtrNew(StrLen(recordP->StartTime) + 1) ;
> >
> > to account for the string being null terminated by StrCopy.
> >
> >
> > -Roger Flores
> >
> >
> >
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 19:26:35 -0800
> From: [EMAIL PROTECTED]
> Subject: Emulating Palm IIIx
>
>
>
>
> Hello,
>
> My name is Colm Kiely, and I am developing software for use on PDAs. The
> PDA I am currently using is a Palm IIIx. I downloaded a ROM file from this
> PDA, but I am unable to change the emulation "hardware" options to Palm
> IIIx (it defaults to Palm III, and the drop-down list is all in grey and
> immutable). Every time I attempt to run the Emulator, an error is thrown,
> stating that "this ROM cannot be used to emulate the selected hardware" or
> similar. I have tried re-downloading the ROM file numerous times, and all
> user's guide references relevant simply state that the appropriate
hardware
> can be selected from the dropdown list.
>
> Any advice would be appreciated.
>
> Thank You,
>
> Colm Kiely
>
> Argyle Diamonds,
> 2 Kings Park Road,
> West Perth 6005
> Western Australia
> Australia
>
>
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 20:31:00 -0800
> From: Qun Wang <[EMAIL PROTECTED]>
> Subject: SelectDay error.
>
> Hi, I am developing a Multi-Segment Palm application.
> I have used the Date Select dialog(which calls SelectDay function) in
> several(6) forms in my application. They all works fine.
> Today I suddenly found out all the SelectDay calls in my applcation
> start to crash.
> The error msg I got : Form.c, Line:1272, Object not in form.
> The code in different form all looks like this:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> void SetUserSelDateLabel(Word objID, CharPtr title, DateType aDate)
> {
> SWord month, day, year;
>
> month = aDate.month;
> day = aDate.day;
> year = aDate.year + firstYear;
>
> if (SelectDay (selectDayByDay, &month, &day, &year, title)) file://This
> line caused the crash!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> {
> aDate.month = month;
> aDate.day = day;
> aDate.year = year -firstYear; file://DateType's year field is 7 bits.
max
> value is 127
> SetSelTriggerDateLabel(objID, aDate);
> }
> }
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> The Strange thing is this code was working perfectly until I added some
> new forms several days ago.
> Anyone have any idea? Please help.
> It gonna be some sort of bug in Palm Platform. But how do I get aound
> it?
> Fletcher, I think I am having the same problem as you had. Did you find
> a solution?
> Roger Flores, I am pretty sure the month , day and year is initlized
> correctly.
> Do you have any idea whatelse can cause this problem.
>
>
> Thanks,
>
> - -QW
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 22:04:57 -0800
> From: "LeGrand Decius" <[EMAIL PROTECTED]>
> Subject: Re: Emulating Palm IIIx
>
> I had the same problem.
>
> I was able to get around this by selecting all the options first and then
> choose the PDA type.
>
> I hope this work for you.
>
> LeGrand Decius.
>
> - ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, January 16, 2000 10:21 PM
> Subject: Emulating Palm IIIx
>
>
> >
> >
> >
> > Hello,
> >
> > My name is Colm Kiely, and I am developing software for use on PDAs. The
> > PDA I am currently using is a Palm IIIx. I downloaded a ROM file from
this
> > PDA, but I am unable to change the emulation "hardware" options to Palm
> > IIIx (it defaults to Palm III, and the drop-down list is all in grey and
> > immutable). Every time I attempt to run the Emulator, an error is
thrown,
> > stating that "this ROM cannot be used to emulate the selected hardware"
or
> > similar. I have tried re-downloading the ROM file numerous times, and
all
> > user's guide references relevant simply state that the appropriate
> hardware
> > can be selected from the dropdown list.
> >
> > Any advice would be appreciated.
> >
> > Thank You,
> >
> > Colm Kiely
> >
> > Argyle Diamonds,
> > 2 Kings Park Road,
> > West Perth 6005
> > Western Australia
> > Australia
> >
> >
> >
> >
>
>
>
> ----------------------------------------------------------------------
>
> Date: 16 Jan 2000 22:30:34 -0800
> From: [EMAIL PROTECTED]
> Subject: Re: Emulating Palm IIIx
>
> Thanks! That worked (after I reselected all the already selected options
> :P).
>
> Colm
>
>
>
>
> "LeGrand Decius" <[EMAIL PROTECTED]> on 17/01/2000 14:00:11
>
> Please respond to [EMAIL PROTECTED]
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Colm Kiely/Argyle)
> Subject: Re: Emulating Palm IIIx
>
>
>
>
>
> I had the same problem.
>
> I was able to get around this by selecting all the options first and then
> choose the PDA type.
>
> I hope this work for you.
>
> LeGrand Decius.
>
> - ----- Original Message -----
> From: <[EMAIL PROTECTED]>
>
> > PDA, but I am unable to change the emulation "hardware" options to Palm
> > IIIx (it defaults to Palm III, and the drop-down list is all in grey and
> > immutable).
>
>
>
>
>
> ----------------------------------------------------------------------
>
> End of Digest
>
> To request a copy of the help file, reply to this message and put "help"
in
> the subject. To contact a human, please mail to
[EMAIL PROTECTED]
>
>
