"Praveen Potineni" <[EMAIL PROTECTED]> wrote
> I still get the error even after seperating the FrmGetObjectIndex() and
now
> i get the Bad Chunk header error at :
> pindex=FrmGetObjectIndex(frm, DataCollectorLoginIDFieldField);
>
OK. So we've learnt something. Now the question becomes "why
would this function call produce a bad chunk header when all it's
doing is getting a pointer to that control?". Since a chunk header is
part of the system's memory management storage it's not likely to be
a logic error in the program, but seems more likely that the program
is writing past the end of a memory buffer it owns and accidentally
overwriting the start of the next chunk on the heap (I'm not a PalmOS
system guru so I'm not sure that this logic is valid). The other
alternative is that you're giving PalmOS an invalid value when it's
expecting a chunk pointer or handle. This is by far the luckiest bug
because it will trigger a fault almost immediately (rather than hiding
for a while).
Since the fault is occuring in relation to a form access the first thing to
check is that the form memory hasn't been corrupted by copying more
text to the form title or a label than it has room for. Hmm, although
that wouldn't invalidate the chunk header. Since this is a field it's
possible that the memory handle the field uses to hold the contents
for editing is invalid and that PalmOS checks this, but that seems
unlikely. You're going to have to investigate.
This sort of problem won't produce an error immediately, but will
cause your code to fail the next time it (or the system) tries to use
that chunk so it's almost certain that the bug that's causing this problem
has already occured by the time you get to this line of code. Memory
corruption errors are trouble because they could be *anywhere* in
the code that has executed up to that point. The worst I had took nine
days to trace so I spend a lot of time coding carefully to try and avoid
them. Of course this is all guesswork since I can't debug your code
to see what it's doing (and while I'm happy to debug it for you my rate
is US$50 an hour).
Which leads to...
>
> Also can you elucidate on this:
> Aside from this you might also have a corruption of some sort. Open
> the form structure in the debugger and check that the properties all
> look OK. Store a pointer to the control which is erroring (or work
> through the form's control array) and check that it's data is still valid.
>
The frm variable is a FormType * (FormPtr in PalmOS Pascal-ese)
so if you halt the debugger on that line of code you will be able to open
the structure and check the properties. Many of the flags and such-like
are fairly meaningless, but corruption will usually show up fairly quickly
as incorrect ID's and x,y coordinates.
At the end of this frm structure is an item called objects. Opening this
doesn't seem to give you much information but if you right click and
select 'View Array' you'll get a list of memory addresses that can be
opened to show you the properties for each control in the form. I'm
sure that the first item for each used to say what type it was (button,
field, etc) but the test I've just done under CW7.1 shows them all
as frmControlType. Anyway, if you open the object.control member
you'll see the ID of the control and once you get a feel for it it's fairly
easy to locate a particular control and check it's properties.
In this case I'm not sure what you're looking for or even if you're
looking in the right place, but checking the field textHandle to make
sure that it's valid (zero or a valid pointer) is a start.
Chris Tutty
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
