TOPIC:

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:



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:



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

Dick

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

"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.

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

docs.microsoft.com/en-us/visualstudio/de...windows?view=vs-2022

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

Hello Robert, Karl,

robert wrote:

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 Utils\bBrowser.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

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

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

Hello Robert,

robert wrote:

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 2019\bBrowser.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 www.xsharp.eu/forum/public-3rdpart/3084-bbrowser-errors for the issues following this thread)

Dick

Dick,

ic2 wrote:

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).

ic2 wrote:

bBrowser codeblock called a bCompoundValue

So what was the code in the codeblock ?

Robert

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

Dick,
We found an issue in the build support DLL for X#.
This caused the compiler not to run with the /shared compiler option.
We have fixed that now.
With 2.13 you should see faster builds inside VS, even when you build all projects.

Robert

Hello Robert,

robert wrote:

With 2.13 you should see faster builds inside VS, even when you build all projects.

This is great to know, but is my observation correct that VS has not even a mechanism to detect which libraries changed and need to be recompiled?

Behaviour in VO: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is included. It does still show the red dot however.
Behaviour in VS: when I change something in a library, click Save but forget to recompile and directly run the main program, the change is NOT included. VS does also not show anywhere that I changed something which needs recompilation.

I hope I am wrong but it works (or better not works) this way, I find this extremely poor. Even when checking all Build checkboxes would work faster now, I saw that unchecking all makes starting almost as fast as in VO but in a way I can't risk that as I may be testing code from which parts won't work as it was never recompiled.

Dick

Can anyone either confirm my assumption, see previous message #23289) that VS has no means to detect which libs should be compiled?

Or, better, tell my that I am wrong (and what I should do to avoid to check all libs to build)

Dick

Hi Dick,

When you compile a certain library, then VS (MSBuild actually), assumes by default that all other libraries that have a reference to it, need to also be rebuilt. Libraries that do not reference this library do not get rebuilt, unless you specifically ask to do so, by using REbuild.

Indeed, because there's no repo as in VO, VS can't tell if a change in a library does actually make it necessary to rebuild its dependent ones, that's the downside. The upside is that there are no repo corruptions in VS and other .Net IDEs... Only in the last couple months, I have had so many repo corruptions and VO crashes with the "Sorry" message while testing people's apps in VO first, before porting them to X#, which made me remember how glad I am that I hadn't have to deal anymore with this in the last 10 years or so...

.

Hello Chris,

Thanks for confirming. I haven't seen a corruption in my repo for years but I see the "Sorry" message regularly. That is irritating but fortunately VO is very fast and up and running again in a few seconds. If I would sum all these few seconds it would be only a fraction of the time I have spent to solve the VS problems I had in the same period. Far less than VO's "Sorry" but far more time consuming and often hard to solve, so much more nerving.

I find that the more I work in VS and .Net, the more disadvantages against VO I find. Advantages are there too but they rare and often small.

I am not sure what you mean with "MSBuild assumes by default that all other libraries that have a reference to it, need to also be rebuilt.".

What do you mean by "assume"? I found that after I changed something, with no "Build" checkboxes checked, nothing was compiled and the previous code was executed. But even if it was, if all referenced libraries would recompile after a tiny change in 1 of them, that would not be very helpful either.

Dick

Hi Dick,

By default, all those checkboxes are enabled. When you disable them, indeed Build does not compile the dependent projects automatically anymore.

I didn't even have to wait 1 day before we had another VS issue which costed us more than 1 year VO's "sorry" crashes.

Frank was compiling some small code changes in our X# project but it took extremely long. Also when retrying. We eventually found this great helpful Microsoft Build message:

Error MSB4181 The "Xsc" task returned false but did not log an error. Kleijn C:\XSharp\MsBuild\XSharp.targets 209

Frank cleaned the solution, tried a rebuild. No succes. After the usual VS waste of time Frank reset his computer and then he could rebuild again.

I think I can easily say that Robert eventually solved VO's repo issues, only regular (3-4 times a week) but easy and quick to solve crashes remain. But Microsoft has never solved (and will never solve) it's crappy software which errors will always cost substantial time to overcome, invariably after trying dozens of different suggested tricks due to the fact that Microsoft has never been able to create error messages which make any sense, let alone help to solve an issue.

Which, I think, is clearly illustrated with the above error which appeared truly out of the blue.

Dick

Dick,

I would love to blame Microsoft for all errors that occur, but in this case the error is probably in our code.
XSharp.targets is our file and line 209 is the location where the xsc.exe process is started.
I wish I could say more about the cause of the error. I need more information for that.

Robert

Hello Robert,

I think we can safely blame Microsoft. It appeared suddenly with no unusual program change and it disappeared eventually after restarting the Pc, once again cleaning the code and rebuilding it. I have seen these situations earlier and the line where it went wrong seems randomly picked by VS. If it was really causing the problem it would have started by a recognizable action and also persist, not disappear after restarting the Pc.

Dick