Now, what I'd also like to be able to do is to put a breakpoint in the source of my client app, explicitly start up my client app in the debugger, and when I hit the breakpoint in the client source, I'd like to be able to step through the client source and then into the source code of my library. In other words, I'd like to be able to step into the source code of a function residing in MyLib.prc just as though it were a function residing in MyLibClient.prc. Is there some way analagous to above that I can tell the debugger that the library's source code resides in the directory structure containing MyLib.prc? If there is, I'd very much appreciate finding out how to do so.
This can't be done with the current V9 debugger, and we are not planning on adding this capability, and it is a pretty difficult task.
The problem is that a shared library call is a system call. The debugger just sees the shared library call the same way it would see a call to FrmDrawForm or StrLen -- it is a system trap. To step into this trap requires a lot of additional logic that isn't in the CW debugger. To complicate things, a call to one shared library looks exactly like a call to any other shared library -- only the leading parameter, the libRef, distinguishes them.
Now, with V9, you can debug your client app and add the shared library to the "Other Executables" pref panel, and the debugger will pull in symbols for both PRC files, and you can set BPs in both. Stepping into the library code still won't work, but if you set BPs on all the routines, you can trace what's happening to some extent.
--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
