Conversion or application of well known VO libraries to X#

[ic2]

We are working on the conversion of 1 large client project from VO to X#. We have converted 1 program which uses a lot of 'general' functionality and this seems to be a good base to start converting the larger projects.

In the program we use the following VO libs. My questions is:

1 Did anyone convert any of these libs, willing to share the X# converted lib?
2 Or is there another strategy to get the functionality of any of these libs in X#? E.g. running Report Pro reports using a VO program?

I realize well that there are better solutions in .Net for at least some of the below libs but apart from info from others how they replaced one or more of these libs, I would like to start wherever possible with converted libs to see if the program still works, and replace with .Net solutions as a second step.

The libs are:
Hoverbutton
Excel automation base class
Word base class

RP2RDD32 Lib
_SE UI XP Base classes (Sven Ebert's toolbar program)

Fab Paint lib
Fab Paintlib control


Dick

[Fabrice]

Hi Dick,
about FabPaint, I suggest you start with the Vulcan version of that library : It is available at www.fabtoys.net; and moving to X# should not raise some complex errors.
Sorry, I currently have little time to dedicate to that task, but I would be happy to publish your X# version when it's done.

Fab

[robert]

Dick,
There is really no need to convert Excel or Word ole classes. Simply add a reference to the Excel and Word interop assemblies and choose "embed interop types" for these references. That will include the type information from these type libraries in your code, so you even don't have to include the assemblies with your app.
And for ReportPro you should use the RP2 version that we have created. Mail me a proof of purchase for RP2 and I will grant you download rights to the RP2 binaries. If you also have a RP2 source lincense I will grant you the rights to the RP2 source as well.

Robert

[ic2]

Hello Fabrice,

We're now on 90 errors - after setting the program to Allow Unsafe code, because of the use of pointers.

This is one error we get often:

Warning XS9032 This entity type cannot return a value. Return value ignored. Fab_Ctrl D:XSharpProjectsFabPaintlibsXsharpFab_CtrlBitmap Button.prg 527

XS9032 is skipped in the help file. THis is the code:

ASSIGN ImageList( oNew AS ImageList )
SELF:_oImgList := oNew
SELF:Update()
RETURN SELF:_oImgList

What's wrong with it?

Same question for error XS0108 which is also skipped in the help:

Warning XS0108 'MultiImageWindow.Close()' hides inherited member 'StdImageWindow.Close()'. Use the new keyword if hiding was intended. Fab_PaintLib_Test D:XSharpProjectsFabPaintlibsXsharpFab_PaintLib_TestWnd MultiImgView.prg 11

METHOD Close()
//
SUPER:Close()
//
SELF:oMulti:Destroy()
//
return self

If I know what to do here I think we may have a working X# FabPaintLib soon.

Dick

[Chris]

Hi Dick,

About the first warning, it is simple, as its message says, ASSIGNs in .Net do not return values, so the RETURN <xxxx> line is being ignored. You can either chose to remove the code after each RETURN, or simply ignore the warning and disable it.

About the second one, by default METHODs in .Net are not VIRTUAL, meaning that you cannot override a method of a base class by redefining it in a child class, like we do in VO, this instead creates a completely new method, from the CLR's point of view. In order to make a (base) method overrideable, you must explicitly mark it with the VIRTUAL keyword. Or, you van simply enable the "All instance methods virtual" project option, which tells the compiler to make all methods VIRTUAL by default, for compatibility with VO. Both ways should get rid of the warning (which in this case it is important to resolve it, do not simply disable it).

Chris

[ic2]

Hello Chris,

Do you ever sleep

About the Assign: it's that simple; I actually didn't realize it didn't need the return value to work and thought I had to work out an alternative for Assign. E.g. there's some code saying:
if self:oImg:GetBackgroundColor( @RGB )
return oColor
endif
which seems to imply that the return value has some actual use.

The VIRTUAL solution I have to check after solving missing assembly errors. After removing the Returns I still get 90 errors but the "virtual errors" currently disappeared.

May I suggest to paste the above clear replies in the help file (as these errors are currently undocumented)?

Dick

[Chris]

Hi DIck,

Do you ever sleep

Yes of course, during the day, when being awake while having constantly over 35C is a waste of time

About the return value in ASSIGNs, in VO you could use something like:

Code: Select all

CLASS TestClass
ASSIGN TestAssign(n) CLASS TestClass
RETURN n * 2

FUNCTION Start() AS VOID
LOCAL o AS TestClass
LOCAL n AS INT
o := TestClass{}
n := o:TestAssign := 1
? n // prints 2 in VO

so you could indeed use the return value of an assign. I don't think this was good, it could easily make the code impossible to understand and anyway it's not supported in .Net (returning a value from ASSIGN), so it is ignored by the compiler and a warning is reported.

About the documentation, problem is that in the docs we need to use more formal language, while explaining stuff here in the forum in a more casual way is a lot easier. But if Robert thinks it's good enough, he will include the explanation to the docs.

Chris

[wriedmann]

Hi Dick, hi Chris,

this is the classical case for which the Documentation Project was built: document something in a informal way....

Since Chris gave me the permission to use his messages here to build entries in the Docs wiki, I'll add them immediatly.

Wolfgang

[wriedmann]

Hi Dick, hi Chris,

I have added two articles to the wiki now:
https://docs.xsharp.it/doku.php?id=assign_no_returnvalue
https://docs.xsharp.it/doku.php?id=virtual_methods

Since you both have the rights to write in the wiki, please feel free to modify these if you like or feel it should be explained better.

At least the article about the virtual methods need samples, but unfortunately I have not the time now, and will add them later (if they are not added by you).

Wolfgang

[lumberjack]

Hi Dick,

About the Assign: it's that simple; I actually didn't realize it didn't need the return value to work and thought I had to work out an alternative for Assign. E.g. there's some code saying:
if self:oImg:GetBackgroundColor( @RGB )
return oColor
endif
which seems to imply that the return value has some actual use.

You should be careful how you interpret things. The above example is a method call, not a property/assign. I would suggest you start as quickly as possible to use PROPERTY GET SET instead of ACCESS/ASIGN

Regards,
Johan