I sort of solved this one. I started up a brand new project in CW7 as a
multi segmented C application. Then I copied my C and H files and so forth
from my old project to my new project. I recompiled and it seems to handle
breakpoints just fine. Weird.
Jim
"Steve Mann" <[EMAIL PROTECTED]> wrote in message
news:44314@palm-dev-forum...
>
> >Put a break point in the open event of Form A.
> >Press Button B (to open form B).
> >The debugger stops in break point of Form A but opens Form B. (A
> >doesn't call B)
>
> I thought that's what you were describing, but I wasn't sure. The
> addition of the startup form with two buttons makes it clearer.
> Strange behavior.
>
> >I wouldn't really care except that I am trying to debug an event when I
open
> >Form A. Of course, when I open Form A it does not stop at the break
point
> >in Form A. But the code acts as though it went through it.
>
> >I was going on the assumption that using too much global space might be
> >overrunning stack or something else and producing a memory stomp which
was
> >leading to the writing directly to screen error.
>
> That's possible. Since the problem's gone, you'll never know.
>
> >I may now have changed the area where the global space and this other
area
> >collide and now I am getting different behavior.(since something else is
> >stomping on an area of memory.)
> >
> How do you know something else is stomping on an area of memory, or
> are you just assuming that? Is the only problem/symptom the form
> opening behavior you describe?
>
> >I am a little light on how Palm manages memory and yes I have read the
> >manuals. Is what I think is happening a reasonable explanation?
>
> Personally, it doesn't sound like a stack problem. Usually if your
> stack gets messed up, you crash and burn in horrible ways pretty
> quickly. I would guess one or more bugs unrelated to the stack. Are
> you storing form IDs in globals or other variables?
>
> Two suggestions:
>
> -- Run the simplest case you can to reproduce either of the problems.
> Then, remove all your object code, remove all breakpoints, recompile
> everything, set one breakpoint at the beginning of the each of the
> form event handlers, and run that same sequence again. If you're
> running under POSE you might want to look for nil events, and set the
> breakpoint _after_ eliminating the nil events. POSE can generate a
> lot of them, and they just get in the way.
>
> --Alternately (or as a supporting technique), turn on logging in
> gremlins, get rid of the breakpoints, and make sure that when you hit
> the Form A button, the proper events happen. Again, use the simplest
> case that reproduces either of the problems.
>
> Without seeing more of your code (which I doubt this mailing list
> would like to see), it's tough (at least for me) to make any further
> suggestions. Undoubtedly, someone else out there has some other ideas.
>
> Regards,
> Steve Mann
> --
> -------------------------------------------
> Creative Digital Publishing Inc.
> 1315 Palm Street, San Luis Obispo, CA 93401-3117
> -------------------------------------------
> 805.784.9461 805.784.9462 (fax)
> [EMAIL PROTECTED] http://www.cdpubs.com
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
