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