Miscellaneous questions about converting VO code to X#

[Chris]

Hi Kees,

Defining the LOCAL AS USUAL causes another late bound call, which is implemented with an intermediate function in the runtime. Please change that to AS DataServer (or AS DBServer etc, depending on the type of the server object you actually use) and it should work well (and with better compile-time checking).

[Kees Bouw]

Thank you Chris, now it does work, although I still get the first message starting with "Your step-into request resulted" etc. But when I click Yes (=continue to be notified) the debugger does continue in the Find() method. No message about "OOP.prg not found". So a definite improvement! I don't like USUAL's myself and I never use one if I can avoid it (in this case Server was a USUAL so I thought that is what the intermediate variable should be), but I am working with an old VO application converted to X# so I find many things that are not up to standard. Even things that make me wonder how it could ever have worked in VO because it is clearly wrong.

Kees.

[Kees Bouw]

The VO windows have been converted to VO-forms in X#, with the help of the VOXPorter, and they work. Now I would like to transform them one by one to Winforms. I could try to use the Winforms versions also created by the VOXPorter but as I understand it only the layout is converted, not the logic behind the controls. So that will require some work. But I have heard about the XGUI classes, which I think is basically Winforms that behaves like VO-forms. Is that correct? Where can I find more information about using the XGUI classes? Or are they still being developed? What would the advantages be to use XGUI instead of native X# Winforms, coming from VO?
Thank you for any help!

[wriedmann]

Hi Kees,
the XGUI classes are a replacement for the VOGUI classes.
That means that you can replace the VOGUI classes with the XGUI classes.
Instead of being based on the Windows API they are using Windows Forms as technical base and can also be used in the AnyCPU mode. That means also that any GUI tool that is based on the VOGUI classes like ReportPro and the bBrowser are needed in a version compatible to the XGUI classes.
And since they are a replacement, they cannot be used in the same application and parallel to the XGUI classes.
Wolfgang
P.S. I had presented them shortly at the X# Summit in Memmingen and have also proposed a session on them for the next X# Summit in Munich

[Chris]

Hi Kees,

In addition to what Wolfgang said, another advantage is that since the app will be pure Windows.Forms under the hood, it will be a lot easier to integrate 3rd party windows forms windows and controls to it, including controls in the existing windows themselves. Also the windows use unicode texts which makes its easier for multilingual apps, while VOGUI can use one ansi codepage only.

Be warned that they are not finished yet, though, so some things are still not working, like custom drawing in controls like listview, combobox etc. Also since they are strongly typed, this means they require some changes in your code, for example

METHOD EditFocusChange(oEditFocusChangeEvent) CLASS DataWin

needs to be changed to

METHOD EditFocusChange(oEditFocusChangeEvent AS EditFocusChangeEvent) AS VOID CLASS DataWin

[Kees Bouw]

Hi Wolfgang and Chris,

Thank you for your replies. If I understand you correctly, then:

- XGUI replaces VOGUI which means that all windows have to be changed at once, I can't do it one by one.

- I would need a new version of bBrowser which does not exist yet.

This makes it impossible to start using XGUI at this time. Although a very exciting and promising development, I shall have to wait

Kees.

[wriedmann]

Hi Kees,

unfortunately this is correct.

Wolfgang

[Kees Bouw]

While converting a VO.DataDialog to a System.Windows.Forms.Form I ran into some problems, maybe because the whole setup is not straightforward. In the VO code, it starts with a class that has a lot of "helper" methods, this class inherits from VO.DataDialog.Then there is a second class with another set of helper methods that inherits from the first class, and then there is a third class that is the actual window which inherits from the second class. So it is organized like this:

CLASS First INHERIT VO.DataDialog -> CLASS Second INHERIT First -> CLASS Third INHERIT Second

Only the third class has a real window with an .xsfrm and a .rc file.

This works in VO and even in X#. However, if I change it so that the first class inherits from System.Windows.Forms.Form and change the actual window to Winforms with a .resx and a designer file, strange things are happening. Sometimes a weird error but most of the time VS just disappears without any message or error when I double click on the window to edit it. My question is: should this construction work in principle, I mean that a class inherits from Winforms but the actual window is defined several classes further on, or is this "bad practice" and I need to find another solution for the "helper" methods?
The reason it is done this way is probably that there are other windows which also inherit from classes First and Second so the "helper" code does not have to be duplicated.

Kees.

[Kees Bouw]

Ok, so nobody knows an answer to the previous question unfortunately. Next question. The System.Windows.Forms.Form class has a method Close(). How can I override this method without getting the warning "Warning XS0108 'MyClass.Close()' hides inherited member 'System.Windows.Forms.Form.Close()'. Use the new keyword if hiding was intended". Obviously I can't put "VIRTUAL" before the Close() in the system class and putting "OVERRIDE" before the Close() in my own class makes no difference, I still get the warning.

Kees.

[Chris]

Hi Kees,

You just need to use the "NEW" keyword before the METHOD declaration.

About the windows hierarchy, yes this should be supported. What is the "weird error" that you are getting (when you do not get a crash)?
Can you reproduce the problem in a small new test project and send it to have a look?