BlackBox Framework Center

Posted: **Tue Jun 05, 2018 4:55 pm**

I have been away / busy in the last few weeks, and am rather struggling to catch up!

I have just down-loaded version 1031 to try this, and have found the instructions "The debugger is started by executing the specified cmdLine after appending the option /LOAD DevRTDebug" in DevDebugCmds Docu, and "If you want to debug a command M.P then select M.P in a text viewer and execute Dev->Debug Command" in this thread.

I don't know how to do either of these things.

Where do you specify the cmdLine? Is it a field in the usual desktop icon, or do you need to use the Windows Run window?

And how do you open "the Debug tool opened in the attached debugger process"?

Also, does the phrase "The run-time debugger is another BlackBox process ..." need explaining; I don't understand its significance?

Robert

Posted: **Tue Jun 05, 2018 11:15 pm**

Robert,
I agree all of that is confusing.
Here is what I finally figured out.
Just create a menu item like

Code: Select all

	"Debug"	""	"DevDebugCmds.DebugCommand"	""

Then select the command in the module you wish to debug, e.g.

Code: Select all

MyPaint.Run

A tool pops up and variables can be examined.
I am still struggling to understand all of its capabilities.
-Doug

Robert wrote:I have been away / busy in the last few weeks, and am rather struggling to catch up!

I have just down-loaded version 1031 to try this, and have found the instructions "The debugger is started by executing the specified cmdLine after appending the option /LOAD DevRTDebug" in DevDebugCmds Docu, and "If you want to debug a command M.P then select M.P in a text viewer and execute Dev->Debug Command" in this thread.

I don't know how to do either of these things.

Where do you specify the cmdLine? Is it a field in the usual desktop icon, or do you need to use the Windows Run window?

And how do you open "the Debug tool opened in the attached debugger process"?

Also, does the phrase "The run-time debugger is another BlackBox process ..." need explaining; I don't understand its significance?

Robert

Posted: **Wed Jun 06, 2018 11:10 am**

Robert wrote:I have been away / busy in the last few weeks, and am rather struggling to catch up!

I have just down-loaded version 1031 to try this, and have found the instructions "The debugger is started by executing the specified cmdLine after appending the option /LOAD DevRTDebug" in DevDebugCmds Docu, and "If you want to debug a command M.P then select M.P in a text viewer and execute Dev->Debug Command" in this thread.

I don't know how to do either of these things.

Where do you specify the cmdLine? Is it a field in the usual desktop icon, or do you need to use the Windows Run window?

And how do you open "the Debug tool opened in the attached debugger process"?

Also, does the phrase "The run-time debugger is another BlackBox process ..." need explaining; I don't understand its significance?

Robert

Let us improve the wording.

What I wanted to express is that there are two processes involved when using the run-time debugger.
The current BlackBox instance is being debugged by another BlackBox process, the attached debugger.
This is important because sometimes you have to switch between the two applications, i.e.
make one or the other the active application. It is easy to overlook the fact that there are two BlackBox instances involved
unless you look carefully on the Windows task bar.

If the debugger is started as another BlackBox application, it needs a command line, i.e. an exe file
and command line options for starting up. There is no big secrete behind that. It uses what is available in BlackBox.
In particular, it uses the option /LOAD for loading a specific module (viz. DevRTDebug), which
implements the run-time debugger as a background action in the debugger process.

It would be possible to call DevDebugCmds.AttachDebugger explicitly in a menu or via a commander.
Then you can specify the command line for the debugger start. If the defaults are OK, you can
specify the empty string as cmdLine. In that case you actually don't have to call AttachDebugger explicitly
because it is called implicitly in DebugModule and DebugCommand.
When it is called implicitly, it uses "" as cmdLine. This fact is missing in the docu.
When trying to add this to the docu I noticed that it would become easier to describe and easier to use
if AttachDebbugger and registering a command line to be used for the debugger is separated.
In the latest version there is a new procedure RegisterDebugger.

For DebugCommand, the intention was to express that a command must be selected like it is for Dev->Execute.
A command consists of a module name M followed by a dot followed by a procedure name P (M.P) and a text
selection of this kind must exists.
DebugModule is similar but only requires a module name to be selected.

I just noticed that DevDebug.DebugGuard is not required because it is identical to TextCmds.SelectionGuard.
I have removed it now.

For the latest version see http://blackboxframework.org/unstable/i ... 1.1032.zip.
For the diffs see https://redmine.blackboxframework.org/p ... d&type=sbs.

- Josef

Posted: **Wed Jun 06, 2018 12:03 pm**

Just a short note: in the menu the "#Dev:..." is missing at "#Dev:&Debug Command" and at "#Dev:&Debug Module"
- Helmut

Posted: **Wed Jun 06, 2018 2:14 pm**

Zinn wrote:Just a short note: in the menu the "#Dev:..." is missing at "#Dev:&Debug Command" and at "#Dev:&Debug Module"
- Helmut

Thanks. I will fix it with the next upload.

- Josef

Posted: **Wed Jun 06, 2018 9:39 pm**

The latest version can be downloaded from http://blackboxframework.org/unstable/i ... 1.1033.zip.

For the diffs see https://redmine.blackboxframework.org/p ... 6d4852cd14.

- Josef

Posted: **Thu Jun 07, 2018 12:26 am**

Josef,

From a user's point of view much of what you have written is irrelevant.
Do I care if there are one or two blackbox processes? No!

I suggest you begin the Docu with the simplest possible example that will pop up the debug tool.
After that you can have what you have written.

Doug

Posted: **Thu Jun 07, 2018 2:52 am**

DGDanforth wrote:I suggest you begin the Docu with the simplest possible example that will pop up the debug tool.
After that you can have what you have written.

Doug

Hi Doug,
you can try this attached file to test;
1,unzip it to the balckbox.exe directory;
2, cd test/ and click bb.cmd to open a bb client app;
3,ctrl+F12
you will quick get a debugger , do what you want

luowy

Posted: **Thu Jun 07, 2018 7:41 am**

DGDanforth wrote:Josef,

From a user's point of view much of what you have written is irrelevant.
Do I care if there are one or two blackbox processes? No!

I suggest you begin the Docu with the simplest possible example that will pop up the debug tool.
After that you can have what you have written.

Doug

I think we must distinguish between the user manual and the developer manual.
The docu of DevDebugCmds belongs to the developer.
The user manual is a different document (Dev/Docu/User-Man.odc).
There you can find the following paragraph related to run-time debugging:
"Since BlackBox version 1.7.2 there is also a run-time debugger included for exceptional situations where the post-mortem analysis is not sufficient. The run-time debugger is another BlackBox process that is attached as a debugger to the running BlackBox process. It provides for single-step execution, setting of breakpoints, and more. The run-time debugger can be activated with the commands Dev->Debug Command and Dev->Debug Module after selecting a command or module name in a text document."

- Josef

Posted: **Thu Jun 07, 2018 7:53 am**

Josef Templ wrote:
DGDanforth wrote:Josef,

From a user's point of view much of what you have written is irrelevant.
Do I care if there are one or two blackbox processes? No!

I suggest you begin the Docu with the simplest possible example that will pop up the debug tool.
After that you can have what you have written.

Doug
I think we must distinguish between the user manual and the developer manual.
The docu of DevDebugCmds belongs to the developer.
The user manual is a different document (Dev/Docu/User-Man.odc).
There you can find the following paragraph related to run-time debugging:
"Since BlackBox version 1.7.2 there is also a run-time debugger included for exceptional situations where the post-mortem analysis is not sufficient. The run-time debugger is another BlackBox process that is attached as a debugger to the running BlackBox process. It provides for single-step execution, setting of breakpoints, and more. The run-time debugger can be activated with the commands Dev->Debug Command and Dev->Debug Module after selecting a command or module name in a text document."

- Josef

I suggest the following change

The run-time debugger provides for single-step execution, setting of breakpoints, and more. The run-time debugger can be activated with the commands Dev->Debug Command and Dev->Debug Module after selecting a command or module name in a text document.

Doug

BlackBox Framework Center

issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox

Re: issue-#187 adding a run-time debugger to BlackBox