@MarkGoldberg pointed out the other day that if you start the debugger from the command line it doesn’t find source files properly according to the redirection file.
Today I poked around with it a little and I think I know what is going on. It appears to work just fine when launched from the IDE so why not when you run it directly?!
Note: There are two stub launchers for the Clarion debugger, Cladb.exe and Cladbne.exe the “ne” in the second one stands for “non elevated”. The following appears to work the same for either.
Using Process Explorer from Sysinternals it is possible to see the Command line used to start a process. Let’s take a look at what happens when the you start the debugger from the IDE:
Command line:
"C:\Dev\Clarion\C10\bin\Cladb.exe" -s Debug -c "C:\Users\brahn\AppData\Roaming\SoftVelocity\Clarion\10.0" "C:\Dev\GitHub\ClarionClasses\TilesExample\Example.exe"
Current directory:
C:\Dev\GitHub\ClarionClasses\TilesExample\
If I replicate that in a command line then everything works as expected!
Note: The -c <path> is not necessary unless you have a non-standard configuration path for Clarion.
What is important here, and what makes my example work, is that I have a Clarion100.red file in the same directory as my Example.exe.
If you only need to rely on the RED file in the Clarion \Bin then none of the following matters but if you have any custom redirection going on then this might be helpful.
My local red file looks like this:
As you can see, that specifies a relative path to this RED file:
and from there the debugger is able to find both my local class files, in the _classes directory and the main RED file via the {include %bin%\%REDNAME%} line.
Why does this matter?
Because the Cladb.exe does not appear to accept command line parameters anymore other than the -c and the name of the EXE to debug.
I believe this is because the Cladb.exe and Cladbne.exe are just stubs that launch the debugger via cladbrun.dll and that the other command line parameters that are mentioned in the out of date help file are not passed through.
Conclusion
The debugger is still a valuable tool, you just need to know how to work around it’s limitations. Don’t expect to be able to specify a redirection file, ini file, PID or anything else on the command line.
Use a local RED file if you do anything other than what is in the base RED file.
Keep waiting for SV to the internals of the compiled EXE so that we can finally have an external debugger that works… cough coff 