🚀 go-pugleaf

In article <d1b77224.0304030832.24c726db@posting.google.com>, 
sashley@strattonpress.com says...
> The problem arises when I try to run the program on any of the Palm OS
> v. 4 roms. When I click a repeating button on one of my forms, the
> emulator pops up the error message dialog box and reports a "not a
> label object" error. I tried putting a breakpoint on the
> "switch(pEvent->eType)" line for the relevant form, but the error is
> generated before the program reaches that line. If I hit continue, the
> dialog box closes, and the program seems to continue to run.

This error comes from FrmCopyLabel -- its an error that happens if you 
try to copy a label into a form object that isn't a label.

If you're seeing this and you know you have a real label, then you might 
be modifying some other part of the form and overflowing an internal 
control length -- however, the 4.0 debug ROMs should detect that too.
-- 
Ben Combee <bcombee@metrowerks.com>
CodeWarrior for Palm OS technical lead
Get help at http://palmoswerks.com/

Ben,

You hit the nail on the head. I wonder why the version 3 ROM accepts
the erroneous FrmCopyLabel call.

As I work my way through my program using the version 4 ROM, I keep
running into similar gotchas. So far, I have been able to solve most
of them. Here's one that's got me stumped. My form has a menu, and
when you click on one of the menu items, the form calls a function,
which retrives a bunch of numbers from a database and displays them in
a spreadsheet. If I go directly from my main form to the form in
question (i.e., form A to from C), everything works find. However, if
I go the form in question indirectly (i.e., form A to form B to form
C), the called function (the same code in each case) barfs on this
line: "FrmCopyTitle(pFrm, "loading . . .");" As I said, this exact
same patch of code works fine when it is reached by a more direct
route. When I take the indirect route, I get this error message:

"Primer(1.0) just wrote to memory location 0x00079C74, which is in the
storage heap. In order to protect the integrity of the user's data,
such direct access is not allowed. Instead, applications should use
special Palm OS functions for this purpose."

The only difference I can see between the two situations is that when
the program reaches the offending code by the indirect route, the
program has slightly less stack space left than when it reaches this
code by the direct route. Is this error message a result of stack
overflow?

If so, can I increase the size of the stack?

Thanks again for your help. The end is in sight! (Yeah, right  :)  )

Stephen S. Ashley


Ben Combee <combee@techwood.org> wrote in message news:<MPG.18f62934361dfc6e989a85@news.earthlink.net>...
> In article <d1b77224.0304030832.24c726db@posting.google.com>, 
> sashley@strattonpress.com says...
> > The problem arises when I try to run the program on any of the Palm OS
> > v. 4 roms. When I click a repeating button on one of my forms, the
> > emulator pops up the error message dialog box and reports a "not a
> > label object" error. I tried putting a breakpoint on the
> > "switch(pEvent->eType)" line for the relevant form, but the error is
> > generated before the program reaches that line. If I hit continue, the
> > dialog box closes, and the program seems to continue to run.
> 
> This error comes from FrmCopyLabel -- its an error that happens if you 
> try to copy a label into a form object that isn't a label.
> 
> If you're seeing this and you know you have a real label, then you might 
> be modifying some other part of the form and overflowing an internal 
> control length -- however, the 4.0 debug ROMs should detect that too.

In article <d1b77224.0304041452.7bd6f4a5@posting.google.com>, 
sashley@strattonpress.com says...
> Ben,
> 
> You hit the nail on the head. I wonder why the version 3 ROM accepts
> the erroneous FrmCopyLabel call.
> 
> As I work my way through my program using the version 4 ROM, I keep
> running into similar gotchas. So far, I have been able to solve most
> of them. Here's one that's got me stumped. My form has a menu, and
> when you click on one of the menu items, the form calls a function,
> which retrives a bunch of numbers from a database and displays them in
> a spreadsheet. If I go directly from my main form to the form in
> question (i.e., form A to from C), everything works find. However, if
> I go the form in question indirectly (i.e., form A to form B to form
> C), the called function (the same code in each case) barfs on this
> line: "FrmCopyTitle(pFrm, "loading . . .");" As I said, this exact
> same patch of code works fine when it is reached by a more direct
> route. When I take the indirect route, I get this error message:

FrmCopyTitle requires that the original title defined in the form be at 
least as long as the string to which you're setting the title.  So, if 
the title on the form as defined in Constructor or PilRC isn't at least 
13 characters, that FrmCopyTitle call may overwrite unallocated memory.

The Palm OS 4 debug ROMs have a lot more debugging checks in them than 
previous ROM.
-- 
Ben Combee <bcombee@metrowerks.com>
CodeWarrior for Palm OS technical lead
Get help at http://palmoswerks.com/

Ben Combee <combee@techwood.org> wrote in message news:<MPG.18f80ae59c2a15ce989a89@news.earthlink.net>...
> > As I work my way through my program using the version 4 ROM, I keep
> > running into similar gotchas. So far, I have been able to solve most
> > of them. Here's one that's got me stumped. My form has a menu, and
> > when you click on one of the menu items, the form calls a function,
> > which retrives a bunch of numbers from a database and displays them in
> > a spreadsheet. If I go directly from my main form to the form in
> > question (i.e., form A to from C), everything works find. However, if
> > I go the form in question indirectly (i.e., form A to form B to form
> > C), the called function (the same code in each case) barfs on this
> > line: "FrmCopyTitle(pFrm, "loading . . .");" As I said, this exact
> > same patch of code works fine when it is reached by a more direct
> > route. When I take the indirect route, I get this error message:
> 
> FrmCopyTitle requires that the original title defined in the form be at 
> least as long as the string to which you're setting the title.  So, if 
> the title on the form as defined in Constructor or PilRC isn't at least 
> 13 characters, that FrmCopyTitle call may overwrite unallocated memory.
> 
> The Palm OS 4 debug ROMs have a lot more debugging checks in them than 
> previous ROM.

I don't think the title length is the problem. The new title is 

"loading . . .". 

The title it replaces is 

"Chi Square Sample Size"


As I noted before, the function handles this title change OK when the
form is reached by the shorter route but not when it is reached by the
longer route. That's why I wondered whether the error message might
have been triggered by a stack overflow.