Greetings Lynette,
I almost forgot the most important debugging idea...
it's hard to overstate the helpfulness of...
DO STARTCB WITH .T.
Normally you can simply DO STARTCB and DO MAIN.
During the startup CB builds a cursor of all the programs and classlibs in your PROJECT. It then scans the cursor doing SET PROC TO... and SET CLASSLIB TO... This saves the developer a lot of time not compiling. By default even "excluded" files are included here. You can modify SETUP.prg.
But libraries will corrupt. They bloat and forget how to compile your lovely method code. That when you should:
(1) don't even think. Just follow this approach.
(2) DO PACKVCX. You'll have write this. Something like make a list of all the vcx in your LIBS directory. Open each one like a dbf and pack it. Gets rid of the bloat.
(3) DO STARTCB WITH .T.
This will recompile every library and program. Mine also compiles the DBC but you don't need to.
Oh yeah. Go to lunch. Big projects can take a long time to compile every library. You may want to pare it down to just processing the libs in your application. It's your call.
(4) DO main and go to work. When you distribute your EXE this process is skipped over because cbmeta is compiled into the EXE. It should be at least.
WHY DO STARTCB and not just DO MYAPP?
What is nice about this is that you can now suspend the application.
Open the project.
Open a library.
Modify a class.. that you just saw in the debugger.
Close every thing up and resume. Your changes are now in place. You are changing things in real time.
Whe you DO MYAPP, you must recompile to an APP to see changes.
Pretty cool eh?
Thanks to CT Blankenship for that little tip.
James Sayer
©2001 James Sayer |
