Debugging horror

[ic2]

After a joint session with Frank trying to solve some exceptions I wonder if we can improve getting the required info with the current version of X#, using VS. Earlier I wrote that debugging in VS is a nightmare compared to VO and the story below illustrates it. Hopefully we can do something to improve it....

1 Consider this exception:

XSDebugHorror1.jpg (32.9 KiB) Viewed 800 times

What happens here is that we get "Value can not be null". But what value can not be null? How can I see that? Only some of parameters show a tooltip, here's one which we think it could be. Supposed this uField (the tooltip) actually is the 'null' value, how can I see what's wrong with the value? The tooltip doesn't make any sense to me. The Immediate Window barely works for most entries. And I see nothing useful in the View details.

2 Then, when you click Exception Settings (lower right) you can uncheck Break when this exception type is unhandled.
I hoped to achieve, by doing that, that the program would continue (like in VO) but no! The program now crashed at Self:Exec, which is even worse. And the program didn't break anymore at the problem line. How can I restore this? I now could manage it by Debug > Windows > Exception Settings, in the Exception Settings window one of the icons said Restore default settings and that worked, but from the list of a million or so items I could never have reset the one I just disabled because I don't know which one I had to check (again).

3 Another very frustrating thing is that stepping through the code with F11, this window or alike keeps popping up:

XSDebugHorror2.jpg (47.19 KiB) Viewed 800 times

And yes, in VS Debug/Options, Enable just my code is checked.
How can we get rid of this?

Dick

[robert]

Dick,
From what I can see in the debugger window there is a problem with a codeblock.
The Cb$Src shows the source of the codeblock.
I think this block is defined in the function / method DefineBrowser.
There should be an exception object of type XSharp.Error that you can view.
Try setting up a TRY .. CATCH e AS EXCEPTION .. END TRY
You can then check the e. Most likely it is of type XSharp,Error.
The exception should have a StackTrace property that has the full stack trace.
If you call ToString() on the exception you will get a textual representation of the error message and the stacktrace.
The error message from the prg file from the bCompoundValue probably appears because you are using a debug version of bBrowser.


Robert

[FFF]

"VS Debug/Options, Enable just my code is checked." - i'd suspect, you have to uncheck this - bCompoundValue is NOT your code, so it won't access it.

[VR]

The auto window could also be helpful: The Autos window shows variables used around the current breakpoint.

https://docs.microsoft.com/en-us/visual ... ew=vs-2022

And checking the call stack in the exception details (View Details) also sometimes helps.

[ic2]

Hello Robert, Karl,

The error message from the prg file from the bCompoundValue probably appears because you are using a debug version of bBrowser.
Robert

We use the DLL's in C:Programs and UtilsbBrowser.NET 4 (XSharp Edition)Redistribution Files which is the normal bBrowser installation.

Why would that be a Debug version? How could we check that and how could we obtain a Release version then?

@Karl: Enable just my code on or off makes no difference.

It is really frustrating.

Dick

[robert]

Dick
If you use ILSpy you should be able to look at the assembly properties.
Otherwise I can imagine that I could look with you guys (Teams , Zoom ?) and see what is going on.
It must be something silly that we are all overlooking.

Robert

[TerryB1]

Dick
I don't know if this helps but I have had similar problems when using VS.

Usually there are only a small number of objects involved. (2 or 3).

By introducing an extra statement such as "if object != null" then re-running the debugger it may skip the exception if you've got the right object.

Terry

[ic2]

Hello Robert,

If you use ILSpy you should be able to look at the assembly properties.

First, we have found the issue of question 1. The bBrowser codeblock called a bCompoundValue with an incorrect parameter. However, the fact remains that the error does not tell me which parameter causes the error. Isn't that something which can be made visible? In this case we had 4 parameters and uField was the most likely one to be causing that, but that is not always the case.

Regarding question 2: a bBrowser installation has 2 locations where the DLL's are stored:

C:Program Files (x86)bBrowser.NET 4 (XSharp Edition)Redistribution Files
C:Program Files (x86)bBrowser.NET 4 (XSharp Edition)Assemblies

The 2 DLL's in there are the same.

When I open it one in ILSpy it says:

[assembly. Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)];

This suggest that this is a debug version but I understand from several sources that a release DLL can still include debug info so this isn't conclusive. But I think you are right. I installed the latest bBrowser version and included the DLL straight from the (default) installation path. During a debug session it indeed actually opened a bBrowser .prg from C:Program Files (x86)bBrowser.NET 4 (XSharp Edition)Visual Studio 2019bBrowser.NET 4 (XSharp Edition)bBrowser instead of giving the above mentioned error.

I do have a few more issues which I'll post separately but for now I still have some questions but the major actual problems are solved.

(See https://www.xsharp.eu/forum/public-3rdp ... ser-errors for the issues following this thread)

Dick

[robert]

Dick,

Hello Robert,

First, we have found the issue of question 1. The bBrowser codeblock called a bCompoundValue with an incorrect parameter. However, the fact remains that the error does not tell me which parameter causes the error. Isn't that something which can be made visible? In this case we had 4 parameters and uField was the most likely one to be causing that, but that is not always the case.

I understand what you are saying. But it is not so easy as you might think. Maybe this is possible, maybe not. We need more information from you to answer that:

Codeblocks follow the "Clipper calling convention". This means that you can pass in as many parameters as you want.
To implement that we create a so called parameter array with the values of the codeblock parameters.
Inside the codeblock the elements from the array are extracted and assigned local variables with the parameter names that you declared for your codeblock.
If you are passing in less values than declared, then we assign NIL to the parameters that have no matching value.

It may be easier to explain this when you show us your code (as always).

bBrowser codeblock called a bCompoundValue

So what was the code in the codeblock ?

Robert

[ic2]

Hello Robert,

We solved the codeblock issue. Yes, something was wrong in the codeblock . But also: the debugger does NOT show which of the parameters caused the error. And it is not clear what was wrong when the run time error pops up.

Second problem with VS versus VO: Yes, I can uncheck all Build checkboxes. The program then starts very fast...because it doesn't compile anything. You have to keep track on what you changed yourself and select Build manually for each changed project.

In VO I can just start my main program and VO compiles what needs to be compiled. You also clearly see what is changed, until entity level.

In VS I have the choice between huge waiting times and a lot of manual labour with a huge chance you forget to rebuilt some changed code.

I call that (again) a huge step backward from VO to VS.

Dick