xsharp.eu

In the converted VO/X# project we use bBrowser for X#. This bBrowser yields 1000's of warnings, probably this is why compiling tasks so much time. I am not sure why the latest bBrowwer is of April last year and why it gives so many warnings, probably the same problem as the other issue I just posted.

Anyhow, I thought we should recreate the bBrowser DLL's (source is included) however, this gives 1 error and also a lot of warnings:

The error in method EditClose() as logic is:

XS9109 Argument 'arg' may not be passed with the '@' prefix


if bConvertLogicToUsual(uValue, self:PropertyGet(#LogicValueIdentifier, NULL_ARRAY), @uTemp)

The warnings are all like this:


Warning XS9043 'DragAcceptFiles' is ambiguous. Could be Method 'VOGUIClasses.Functions.DragAcceptFiles(PTR, logic)' in VOGUIClasses or

Warning XS9066 Symbol 'Empty' is ambiguous. Could be 'XSharp.RT.Functions.Empty(USUAL)' or 'bTools.bBrowser.bCell.Empty()'. Using the

I wonder if everyone using bBrowser is solving this 1 error and 174 warnings or if there's another way to compile this without error and the warnings?

Dick

Hi Dick,

For the error, you need to go to the declaration of the bConvertLogicToUsual() function and change the last parameter from "uValue AS USUAL" to "uValue REF USUAL" (since the param is indeed intended to be used by reference in the code).

I think Joachim has already updated the official bbRowser code to take care of this error and the warnings you mentioned.

Dick,

In my copy of bBrowser the function bConvertLogicToUsual is declared as
As you can see the 3rd argument is declared "AS USUAL".

Previous versions of X# did not report an error here, they were passing the memory location of the parameter (in your case uTemp) to the function, but I am sure that was not what Joachim had in mind.
The last parameter declaration needs to be changed to
The other warning is relatively new and I suspect that Joachim has not looked at bBrowser for X# in a while.
You can disable the warning in the project properties dialog to get rid of it, or fix the issue by changing the code.

The problem here is for example that the bCell class has a method Empty() and there is also a function Empty() in the runtime.
The code
inside the bCell class .
This code could both be calling the Empty() functon in runtime as well as the method.
The reason for this is that the SELF: prefix is not necessary in .Net when you call a method inside code from the same class.

You can also fix this by enabling the new compiler option "Enforce Self" on the Language Properties page.

If you enable this then there is no ambiguity anymore and the compiler "knows" that the code wants to call the runtime function because there is no SELF: in front of Empty().


Robert

Hello Chris,

Chris wrote: I think Joachim has already updated the official bbRowser code to take care of this error and the warnings you mentioned.

That was basically my question, as on https://bbrowser.net/index.php/en/ the latest version seems to be 4.4.33 of 2021-04-11. Where did you find a bBrowser version without these errors/warnings?

I prefer not to need to make changes in an external tool to run it without errors/warnings.

Dick

Hello,

Referring to this post:

https://www.xsharp.eu/forum/public-prod ... rary#21435

Are we the only user of bBrowser for X#?

We have spent a few hours together to find the solution for a non starting program caused by bBrowser DLL's which were outdated and didn't work anymore with X# 2.10.

I know that X# is not the 3rd party tools supplier for all, but maybe you can encourage suppliers like Joachim to issue a new version with every new X# version, if necessary?

Which also leads to the question: does every new X# version require recompiled bBrowser DLLs? I seem to remember that sometimes you can still use a version of external DLL's compiled earlier?

Dick/Frank

Hi Dick,
I'm still using a bBrowser DLL from September 2020 with the latest X# build: This is a precompiled version, not more a self compiled one.
Wolfgang

Hello Wolfgang,

That makes me even more wonder why the whole project didn't start (details in
www.xsharp.eu/forum/public-product/2893 ... rary#21435) until we recompiled the bBrowser DLL's and included these......


Dick

Dick,
Your version was older (was using X# 2.1). It is as simple as that.
Wolfgang has a version that was compiled to X# 2.6 or later.

Robert

Hi Dick,
and please let me add a comment from an X# user standpoint: I'm really happy that the team maintains the "2.6.0.0" version - this saves us the version upgrade nightmare we had in VO.
I remember to have had a discussion about this with Robert in the early times of X#.
For sure it costs more time to the development team but it is definitively worth the time.

And I hope that Robert will be able to deliver new versions of 3rd party products when he needs to change the version sometimes in the future.

Wolfgang

P.S. of course Robert is right that my bBrowser binaries are compiled for 2.6 otherwise my applications would not run

robert wrote: Your version was older (was using X# 2.1). It is as simple as that.
Wolfgang has a version that was compiled to X# 2.6 or later.

Ok. so this message is for Joachim. We have ordered the update on 29-9-2021 and the confirmation included a file bBrwNET4_XSE_v4.3.29_Setup.exe.

It would be a good idea that a setup sent with an order in 2021 is not compiled with an X# of 2019....

My advise is to make your products a bit more expensive so efforts like these are paid better

Dick