I did not get any such messages. Since I did not use either C++ or linux. 
But in past, in one of  the mails I had read about a similar problem, what 
he did was to rename his code files from .c to .cpp. and it worked for him. 
You also can try the same.
Good luck,
Kamal




----------
From:  Palm Developers Forum List [SMTP:[EMAIL PROTECTED]]
Sent:  Sunday, June 06, 1999 1:58 AM
To:  Palm Developers Forum List
Subject:  Palm Dev Forum Digest 6/5/99

-> Re: FldNewField return value stability
     by Scott Johnson <[EMAIL PROTECTED]>
-> Re: "Fatal Exception" in beaming code
     by Scott Johnson <[EMAIL PROTECTED]>
-> PrefSetAppPreferences and version
     by pete moss <[EMAIL PROTECTED]>
-> compiling 21d28 under linux
     by Stephen Johnson <[EMAIL PROTECTED]>
-> RE: largeBoldFont and Constructor
     by "PalmOS at headRUSH" <[EMAIL PROTECTED]>
-> RE: compiling 21d28 under linux
     by Chris Faherty <[EMAIL PROTECTED]>
-> Re: PrefSetAppPreferences and version
     by "Chris Antos" <[EMAIL PROTECTED]>
-> Determining Palm Memory available from Conduit
     by [EMAIL PROTECTED]
-> Re: "Fatal Exception" in beaming code
     by Peter Solderitsch <[EMAIL PROTECTED]>
-> Re: PrefSetAppPreferences and version
     by pete moss <[EMAIL PROTECTED]>


----------------------------------------------------------------------

Date: 5 Jun 1999 00:33:46 -0700
From: Scott Johnson <[EMAIL PROTECTED]>
Subject: Re: FldNewField return value stability

Alan Kennington wrote:
> FldNewField
> returns a pointer to Field, which, if used straight away,
> gives no problems, e.g. in FldSetTextPtr(...).
>
> But if I save the field-pointer and try to use it later,
> very nasty things happen. Obviously it has been moved
> around in memory, I suppose. The FrmGetObjectPtr(...)
> function returns a different pointer at a later time.

You are calling FldNewField (or other "Dynamic UI" function) in the
meantime, right?  Those functions do (generally) cause the form object
to relocate because it is being expanded.  The form's objects are
embedded inside the form chunk so they move along with it.

(This is mentioned on p.176 of Part I of the 3.0 SDK book.)

> But I wonder if the return pointer from the FldNewField(...)
> function was really supposed to return the address of _locked_
> memory.

It does, but any subsequent call to FldNewField (et al) can unlock,
move, and relock the form chunk.  Note that the FormPtr is passed as an
in/out parameter so your code will receive the new pointer after the
form has been relocated.

(Keep in mind that this Dynamic UI stuff is a rather obscure area of
Palm programming that most people never use, so the docs probably don't
cover every "gotcha" like this everywhere they could.)

> The fact that fields in a form do not seem to be lockable
> seems to imply that I can't just save an array of pointers
> to my 66 fields which I create dynamically.

If you are creating all 66 at the same time before using any of them,
just loop to fetch all 66 at the end of the creation process.  But if
you are creating them at various times during the life of the form, then
you do need to re-fetch them.

> Can anyone confirm that programmers really are expected to
> call FrmGetObjectIndex(...) and FrmGetObjectPtr(...)
> every time they want to read/write them?

No, it's common (for non-dynamic Constructor or PilRC forms) to fetch
all needed object pointers into global variables during the frmOpen
event handler, and then just use them directly later.

> It seems like any create/delete/resize action on the fields of
> a form could result in the fields moving around.
> So if I fetch a field-pointer, and then do something
> else with the form, then an access to the field-pointer could
> be invalid.

Not "anything else".  This relocation happens _only_ when you use the
API's to dynamically add and remove whole objects in the form.  All the
other API's for working with field contents, handling lists, setting
attributes, hiding, drawing, enabling, etc., don't cause the form or its
objects to move.

But note that while a field _object_ stays fixed, its _text_ is stored
in a separately allocated heap chunk that does grow and shrink and move
around as the user edits text, but that's a different issue.

> Under what circumstances can I assume that a field-pointer
> will _not_ change, and therefore is safe to use?

When the form is finished being constructed.  For non-dynamic UI, the
form is fully constructed by the FrmInitForm API which returns a locked
FormPtr you can safely use.  But as soon as you call a dynamic UI
function on a FormPtr to construct more objects, it invalidates any
pointers that previously referred to any of its objects.

(You put 66 fields on one form?  Sounds like a 6x11 table.  Did a
regular table object not work in this case?)

- -slj-


----------------------------------------------------------------------

Date: 5 Jun 1999 00:58:58 -0700
From: Scott Johnson <[EMAIL PROTECTED]>
Subject: Re: "Fatal Exception" in beaming code

Peter Solderitsch wrote:
> DOESN'T have their app currently open. Basically, no matter what I've
> tried, when the user taps "yes" to accept the beam data into their
> palm, I get a Fatal exception.
>
> I've already made sure that I'm not using any globals in the code.

Did you verify you are not using any 'invisible' globals that C++
creates?  This includes static class member variables, static local
variables (actually a C feature) and virtual function tables.  You can't
use virtual functions in a no-globals launch code.

> The only thing at ALL that I'm doing is possibly creating a database
> when i handle the receive beam launch code.

Is the database name coded as a literal string your code, and can you
verify the compiler is putting that string in the code segment and not
in the (absent) data segment?  That would crash.  Make sure your project
has PC-Relative Strings turned ON in the Code Generation -> 68K
Processor panel.

> could this be a compiler bug? or is there some other known issue I am
> ignorant of?

Probably not a bug.  IMHO the CodeWarrior compiler is very good.

- -slj-


----------------------------------------------------------------------

Date: 5 Jun 1999 02:20:33 -0700
From: pete moss <[EMAIL PROTECTED]>
Subject: PrefSetAppPreferences and version

what purpose does it serve to write version info into the app prefs with
PrefSetAppPreferences when PrefGetAppPreferences doesnt call it back?
does the system use this version info?  if my app is version 1.2, how do
i format that as an integer for the version info?

pete


----------------------------------------------------------------------

Date: 5 Jun 1999 03:56:00 -0700
From: Stephen Johnson <[EMAIL PROTECTED]>
Subject: compiling 21d28 under linux

Has anyone successfully compiled 21d28 under linux?  I have tried to 
compile
under both 5.2 (with updates) and 6.0 (out of the box) and I have the same
problem with both.  The package compiles fine then at link time I get lots
of error messages that look like this:

/usr/include/g++-2/std/bastring.h(.text+0xd): undefined reference to
`omni_thread::omni_thread(void *, omni_thread::priority_t)'
/usr/include/g++-2/std/bastring.h(.text+0x22): undefined reference to
`omni_semaphore::omni_semaphore(unsigned int)'
/usr/include/g++-2/std/bastring.h(.text+0x30): undefined reference to
`omni_semaphore::omni_semaphore(unsigned int)'
/usr/include/g++-2/std/bastring.h(.text+0x47): undefined reference to
`omni_thread::start_undetached(void)'
/usr/include/g++-2/std/bastring.h(.text+0x77): undefined reference to
`omni_semaphore::~omni_semaphore(void)'
/usr/include/g++-2/std/bastring.h(.text+0x87): undefined reference to
`omni_semaphore::~omni_semaphore(void)'
/usr/include/g++-2/std/bastring.h(.text+0x94): undefined reference to
`omni_thread::~omni_thread(void)'
CPU_MT.o: In function `CPU::~CPU(void)':
/root/Emulator_Src_21d28/BuildUnix/./../SrcUnix/CPU_MT.cpp:31: undefined
reference to `omni_semaphore::~omni_semaphore(void)'
/root/Emulator_Src_21d28/BuildUnix/./../SrcUnix/CPU_MT.cpp:31: undefined
reference to `omni_semaphore::~omni_semaphore(void)'
/root/Emulator_Src_21d28/BuildUnix/./../SrcUnix/CPU_MT.cpp:31: undefined
reference to `omni_thread::~omni_thread(void)'


Some rpm versions:
egcs-1.1.2-12
egcs-c++-1.1.2-12
fltk-1.0.3-1
glib-1.2.1-2
glib-devel-1.2.1-2
glib10-1.0.6-5
glibc-devel-2.1.1-6
libc-5.3.12-31
libstdc++-2.9.0-12

I am not a c++ guy (read I'm an old C dinosaur) and these error messages
don't mean a lot to me.  Any help would be appreciated as I'm trying to 
pull
together an environment to do palm programming under linux.

Thanks


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com


----------------------------------------------------------------------

Date: 5 Jun 1999 05:53:21 -0700
From: "PalmOS at headRUSH" <[EMAIL PROTECTED]>
Subject: RE: largeBoldFont and Constructor

I can't seem to get Constructor to use largeBoldFont (Bold 12???). I have 
no
problems with using largeBoldFont within any of my source code.

Bold 12.fon is sitting in my C:\Windows\Fonts directory, I can double click
and view it. It doesn't _appear_ to be corrupt. I have restarted win98 and
it still doesn't work.

I am using CW5 with the latest patch & update.

I am trying to use the font with a label on my main form. Bold 12 is an
option in the pull down menu, but the seclection is not updated (on the
left) after I select it. It also freezes for a couple of seconds after I
select Bold 12.

I thought it was just maybe Constructor displaying it incorrectly, but 
after
compiling my program it still doesn't work.

I thought it just might be my resource file, but I created an entirely new
one, with just the form and the label and it still isn't working.

Any ideas?

PS: Anyone have a full-time programming position open in Boston or NYC? :)



----------------------------------------------------------------------

Date: 5 Jun 1999 08:15:02 -0700
From: Chris Faherty <[EMAIL PROTECTED]>
Subject: RE: compiling 21d28 under linux

On 05-Jun-99 Stephen Johnson wrote:

> Has anyone successfully compiled 21d28 under linux?
>
> /usr/include/g++-2/std/bastring.h(.text+0xd): undefined reference to
> `omni_thread::omni_thread(void *, omni_thread::priority_t)'

Add posix.o to the pose_OBJECTS variable in the Makefile.


/* Chris Faherty <[EMAIL PROTECTED]>, finger for PGP */



----------------------------------------------------------------------

Date: 5 Jun 1999 09:40:07 -0700
From: "Chris Antos" <[EMAIL PROTECTED]>
Subject: Re: PrefSetAppPreferences and version

> what purpose does it serve to write version info into the app prefs with
> PrefSetAppPreferences when PrefGetAppPreferences doesnt call it back?

it wouldn't make sense.  that's why PrefGetAppPreferences returns the
version number.


> does the system use this version info?  if my app is version 1.2, how do
> i format that as an integer for the version info?

however you like.  it's totally up to you, since users won't see the 
number.
personally, my prefs version number is independent from the "real" version
number of the app.  (for example, sometimes when the "real" version gets
incremented, the prefs haven't changed so there's no need to bump the prefs
version number).




----------------------------------------------------------------------

Date: 5 Jun 1999 11:04:00 -0700
From: [EMAIL PROTECTED]
Subject: Determining Palm Memory available from Conduit


     I am writing a conduit for my application and I am uploading some
     large data pieces to the Palm Device. Sometimes the device will run
     out of memory. How can I determine how much memory is available on the 
     device from the conduit.



     I have a utility routine on the device for this purpose:

     // return false if there is not enough palm memory left.
     Boolean UtilIsThereEnoughMemory(int nKMemNeeded)   // Mem Needed in K
     {
        ULong ulFreeBytes;
        Err err = MemCardInfo (0,NULL,NULL, NULL,NULL, NULL,
     NULL,&ulFreeBytes);

        return (ulFreeBytes/1024 > nKMemNeeded);
     }


     Thanks,

     Kevin.



******************* NOTE *******************
There may be important message content
contained in the following MIME Information.
********************************************


- ------------------ MIME Information follows ------------------

- --IMA.Boundary.2855068290
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

<<<<<< See above "Message Body" >>>>>>

- --IMA.Boundary.2855068290
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"

Received: from mailer.symantec.com ([198.6.49.176]) by 
smtp-ima.symantec.com
with SMTP
  (IMA Internet Exchange 3.1) id 006DDA63; Sat, 5 Jun 1999 09:38:16 -0700
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
        by mailer.symantec.com (8.8.8/8.8.8) with ESMTP id JAA24728;
        Sat, 5 Jun 1999 09:37:23 -0700 (PDT)
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
        by seattle.3com.com (8.8.8/8.8.8) with ESMTP id JAA15584;
        Sat, 5 Jun 1999 09:37:59 -0700 (PDT)
Received: from ls.3com.com ([192.156.136.82])
        by new-york.3com.com (8.8.8/8.8.8) with SMTP id JAA00772;
        Sat, 5 Jun 1999 09:37:51 -0700 (PDT)
Date: Sat, 5 Jun 1999 09:42:11 -0700
Message-Id: <006101beaf72$5cab1100$85a5fea9@chrisant1>
From: "Chris Antos" <[EMAIL PROTECTED]>
Subject: Re: PrefSetAppPreferences and version
To: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Precedence: Bulk
X-LIST-URL: http://ls.palm.com
Reply-To: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
- --IMA.Boundary.2855068290--



----------------------------------------------------------------------

Date: 5 Jun 1999 18:26:09 -0700
From: Peter Solderitsch <[EMAIL PROTECTED]>
Subject: Re: "Fatal Exception" in beaming code

At 12:53 AM -0700 6/5/99, Scott Johnson wrote:
>Peter Solderitsch wrote:
>> DOESN'T have their app currently open. Basically, no matter what I've
>> tried, when the user taps "yes" to accept the beam data into their
>> palm, I get a Fatal exception.
>>
>> I've already made sure that I'm not using any globals in the code.
>
>Did you verify you are not using any 'invisible' globals that C++
>creates?  This includes static class member variables, static local
>variables (actually a C feature) and virtual function tables.  You can't
>use virtual functions in a no-globals launch code.
>

Yes, it turns out that I wasn't registering the object extension on
cmdSysLaunchSyncNotify. Which works great on the IIIx I've used to test
with. However, the VERY SAME PROGRAM installed on a III, will cause a fatal
exception!! This is something I truly can't figure out, as I have identical
copies of the app installed on 2 devices. Beaming from inside the app to
one of the devices that is NOT inside the app is handled correctly. Beaming
from inside the OTHER app to the device outside results in a fatal
exception, under identical circumstances! Needless to say, I'm wholly
baffled at this point.


Thanks,
- -Pete

- --
Peter Solderitsch
[EMAIL PROTECTED]
http://www.stanford.edu/~petey/


----------------------------------------------------------------------

Date: 5 Jun 1999 21:39:38 -0700
From: pete moss <[EMAIL PROTECTED]>
Subject: Re: PrefSetAppPreferences and version



Chris Antos wrote:
>
> > what purpose does it serve to write version info into the app prefs 
with
> > PrefSetAppPreferences when PrefGetAppPreferences doesnt call it back?
>
> it wouldn't make sense.  that's why PrefGetAppPreferences returns the
> version number.

the docs say nothing about it returning the version number.  they say it
returns a constant if no prefs available, and some other number
otherwise.  it doesnt say what this number is, just suggests that you
compare it to the size of your struct.





> > does the system use this version info?  if my app is version 1.2, how 
do
> > i format that as an integer for the version info?
>
> however you like.  it's totally up to you, since users won't see the 
number.
> personally, my prefs version number is independent from the "real" 
version
> number of the app.  (for example, sometimes when the "real" version gets
> incremented, the prefs haven't changed so there's no need to bump the 
prefs
> version number).




does the prefs database ever get deleted?  is that one thing that gets
removed when an app is deleted?  if so, what if you dont delete the app
but just overwrite it with a new copy that may create a new 'version' of
the prefs.  does the old version ever get deleted?


pete


----------------------------------------------------------------------

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]

Reply via email to