> I've spent a lot of time debugging through operating system code,
> starting with the call to FrmAlert. I'm doing it on Windows,
> hence don't have PalmDebugger with its ability to set breakpoints
> on traps. It's been exceedingly tedious -- since CodeWarrior and
> the Emulator together don't provide any capability for
> breakpoints within system code,
PalmDebugger for Windows comes with the Palm OS 3.5 SDK, as well as the
Handspring tools.
Also, Poser offers a totally *excellent* way to establish breakpoints, as long
as you can rebuild it. I often program breakpoints right into the core "fetch
an opcode an emulate it" loop. These breakpoints can have abitrarily complex
conditions, can be in "ROM", can be of the "break if the PC is this value" or of
the "break if this memory location changes" variety, and don't really slow down
execution that much.
To track down the problem you're running into, I might run Poser under the VC++
debugger and put a breakpoint in Poser's Platform::CommonDialog routine. This
is the function that is ultimately responsible for showing the dialog. I'd then
start walking the window list to see what was in it.
Another thing you could is patch ErrDisplayFileLineMessage in your Palm
application. Then use CodeWarrior to put a breakpoint on your patch. When the
system calls ErrNonFatalIf(condition), your patch will get called, causing
CodeWarrior to break into its debugger. Then you could use the CodeWarrior
debugger or the console window to walk the window list.
-- Keith Rollin
-- Palm OS Emulator engineer
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
