xsharp.eu • VO Application ported to X#

xsharp.eu

The XSharp Forum
https://beta.xsharp.it/phpBB3/

VO Application ported to X#

https://beta.xsharp.it/phpBB3/viewtopic.php?t=315

Page 1 of 5

VO Application ported to X#

Posted: Fri Jul 14, 2017 8:53 am
by wriedmann
Hello,

yesterday I was able to migrate my Dictionary Editor to X#.(it is a tool to design databases and maintain the string tables for translations)

This is a screeshot of the VO version:
DictEdit_VO.png
DictEdit_VO.png (299 KiB) Viewed 638 times
and this of the X# version:
DictEdit_XS.png
DictEdit_XS.png (322.93 KiB) Viewed 638 times
Wolfgang

VO Application ported to X#

Posted: Fri Jul 14, 2017 1:01 pm
by Chris
Hi Wolfgang,

Thanks for sharing! Personally I already know the answer, since we've talked also by email, but maybe you could share also here your experience with porting the app to x#?

Obviously porting a VO app to x# is not a click and go thing, it requires preparation, effort and some patience for sure! But I think that after you gain some experience with this, it becomes much easier. If you'd like please share some of this, so other people know what to expect as well. When/if you have some time to do this of course.

btw, of course this goes also for everybody else who have ported their VO apps (or some of them)!

TIA,
Chris

VO Application ported to X#

Posted: Sat Jul 15, 2017 4:19 pm
by wriedmann
Hi Chris,

So, if this migration interests someone, I'll post a few articles about it in this thread (a too long article is hard to read and hard to write).

First, let me explain the structure of my VO applications:
  • The base library is the wLib2, that is about 20 years old and is enhanced when needed, at least once a month. It contains the base classes for servers, controls and windows and a lot of other functions and classes. This library contains only handwritten code and is shared between different projects through external modules.
  • Then there is the BasicMapi lib, that contains basic mail functionality and DynMenu, the basic classes for dynamic menus (I don't use the menu editor because most menus are to build depending on the current user
  • The next library is wLibDlg, that uses the first three libraries and contains the most used dialogs, like LookupDialog, ChoiceDialog and about 20 others.
  • Next in the list is wStdBrowser, that uses bBrowser 4, defines my bBrowser base class and the standard databrowser window from which nearly all databrowser windows are inherited, and the relative filter functionality.
  • And then, as last in the list, I have wErrorsys, my base error handler.
There are much more libraries, but they are loaded either dynamically like the Zip (using Compression Plus) or the report classes (using VPE), or used only by a few applications like the Vo2Ado or the MySql lib.

As you can immagine, first candidate in the migration process was the wLib2 library.

Since my libraries and my applications are living, I need the possibility to repeat the migration often, until all of my VO applications (about 50) are migrated to X#.
And the basic rule is to not change anything in the X# version of the library that is not changed also in the VO version.

And as last note: I have licenses to Vulcan 4 (as I'm currently subscribed also to VPS) and to the bBrowser4.NET.

Wolfgang

Preparations and first migration of wLib

Posted: Sat Jul 15, 2017 4:52 pm
by wriedmann
Before starting the migration of my most important library, I have imported the source code of the Vulcan version of the VO class libraries into my XIDE projects.
Then I have changed the names of the libraries from VulcanVO* to XSVO*, changed the compiler from Vulcan to X#/Vulcan dialect and compiled them.
xsvo_project.png
xsvo_project.png (5.26 KiB) Viewed 638 times
Another note: on my C drive, I have a folder called DevNETLibs, where I put all compiled versions of my libraries:
devnet_libs.png
devnet_libs.png (89.6 KiB) Viewed 638 times
Upon my request, Chris has added a special function in XIDE to copy the binaries of a project to a directory, and I use this funtionality to maintain my c:devnetlibs directory content up to date:
xide_copy_binaries.png
xide_copy_binaries.png (14.44 KiB) Viewed 638 times
When using then the libraries in an application references, I select them from the relative c:devNETlibs folder.

Back to the migration process itself: I created a new XIDE project, called VO to X# migration, using the folder C:XSharpXIDEProjectsVO_XS_Migration.

Then I fired up the VO-xPorter, selected the most recent version of my wLib2 AEF and used the following settings:
xporter.png
xporter.png (61.98 KiB) Viewed 638 times
Two settings are very important:
  • the output folder points to the Applications directory of the new project
  • and the "do not overwrite project files" is checked
These settings are important so I can repeat the migration process how often as I like without the need to reconfigure the projects settings after each run.

After xPorting the AEF, I added the application through the Project - Add application context menu:
add_application.png
add_application.png (33.76 KiB) Viewed 638 times
After this, the application was ready to be compiled, and I can assure that I was shocked about the number of compilation errors and warnings I received.

Please read the next message about some solutions I have adopted.

Errors and fixes - Part 1

Posted: Mon Jul 17, 2017 4:03 am
by wriedmann
After porting my library the first time and fixing the references (replacing the VulcanVO* libraries by the XSVO* libraries), I was really surprised how few errors I had:
CompileErrors_Step1.png
CompileErrors_Step1.png (96.56 KiB) Viewed 638 times
The 2 errors were only delegates added by xPorter:

Code: Select all

delegate DictClose_delegate() as void pascal
Easily changed to

Code: Select all

delegate DictClose_delegate() as void
and

Code: Select all

delegate EnumWindowsProc_delegate( hWnd as ptr, aWindows as array ) as word callback
to

Code: Select all

delegate EnumWindowsProc_delegate( hWnd as ptr, aWindows as array ) as word
These two issues will be fixed soon in xPorter.

Fixed these two, on the next compile the errors changed (with warnings hidden as I would concentrate on errors first):
CompileErrors_Step2.png
CompileErrors_Step2.png (17.25 KiB) Viewed 638 times
I will list every type of error only once - and all changes were made on both the VO and the X# side, so I had code synchronized. Larger changes were only made on the VO side, and then moved to X# with a new xPorter run.

Code: Select all

error XS0029: Cannot implicitly convert type 'Vulcan.Codeblock' to 'string'
in this part of code:

Code: Select all

if cValidBlock == NULL_STRING
  cValidBlock := MCompile( cValidString )
endif
change to

Code: Select all

#ifndef __XSHARP__
if cValidBlock == NULL_STRING
  cValidBlock := MCompile( cValidString )
endif
uResult := MExec( cValidBlock )
#else
if oValidBlock == null
  oValidBlock := MCompile( cValidString )
endif
uResult := MExec( oValidBlock )
#endif
as MCompile has another definition in the Vulcan runtime. This correction fixed the first two errors.

Next error after recompile:

Code: Select all

error XS0619: 'Functions._RegisterExit(void*)' is obsolete: ''_RegisterExit()' is not supported.  Use an event handler added to the AppDomain.CurrentDomain:ProcessExit event instead'
on this code part

Code: Select all

if lInit == false     
#warning Callback function modified to use a DELEGATE by xPorter. Please review.
// _RegisterExit( @AxitGlobal() )
static local oAxitGlobalDelegate := AxitGlobal as AxitGlobal_Delegate
_RegisterExit( ;
System.Runtime.InteropServices.Marshal.GetFunctionPointerForDelegate(oAxitGlobalDelegate) )
  lInit := true
endif
This code was changed by the xPorter, and since I don't think the .NET runtime needs the RegisterExit anymore, changed to:

Code: Select all

#ifndef __XSHARP__
if lInit == false
  _RegisterExit( @AxitGlobal() )
  lInit := true
endif
#endif
Next error:

Code: Select all

error XS0619: 'Functions.Buffer(dword)' is obsolete: ''Buffer()' is not supported, use MemAlloc() and MemFree() instead'
on

Code: Select all

cBuffer:= Buffer( 4096 )
easily changed to

Code: Select all

#ifdef __XSHARP__
cBuffer := Space( 4096 )
#else
cBuffer := Buffer( 4096 )
#endif
The next error

Code: Select all

error XS9035: The first argument to PCall must be a 'typed function pointer'.
on

Code: Select all

PCall( ptrFunction, @strWinOsVersionInfo )
was changed to

Code: Select all

#ifdef __XSHARP__
PCallNative<int>( ptrFunction, @strWinOsVersionInfo )
#else 
PCall( ptrFunction, @strWinOsVersionInfo )
#endif


Next series of errors:

Code: Select all

error XS0246: The type or namespace name '_GCDUMP' could not be found (are you missing a using directive or an assembly reference?)
in a function that dumped the current memory for diagnosis. Since the .NET garbage collector is totally, different, I decided to remove the entire function by adding an #ifndef __XSHARP__ before and a #endif after.
The same proceeding was used then on the error

Code: Select all

error XS0619: 'Functions.Memory(int)' is obsolete: ''Memory()' is not supported'
Next (and last error for this article):

Code: Select all

error XS0619: 'Functions._VOLoadLibrary(string)' is obsolete: ''_VOLoadLibrary()' is not supported, use VulcanLoadLibrary() instead.'
repeated several times on various dynamic loads of DLLs:

Code: Select all

hDLL := _VOLoadLibrary( cDLLName )
if hDLL == null_PTR
  ErrBox( oWindow, StrTran( 'library %1 not found", "%1", cDLLName ) )
  return false
else
  hProc	:= GetProcAddress( hDLL, String2Psz( "CPPlusInitDLL" ) )
  if hProc == null_ptr
    ErrBox( oWindow, "error on initialization" =
    return false
  endif
  PCall( hProc )                                                             
  if IsClass( #ZipClass )
    lRetCode := true
  else
    ErrBox( oWindow, "error on initialization of " + cDLLName )
    return false
  endif
endif
Since this code cannot work with X# as .NET works in a completely different manner, and DLLs are to be loaded with Reflection, I decided to not implement this for the moment, so my code was changed to:

Code: Select all

#ifdef __XSHARP__
ErrBox( oWindow, "error on initialization of " + cDLLName )
return false		// TODO 
#else
... remainder of code
#endif

Errors and fixes - Part 1

Posted: Mon Jul 17, 2017 11:57 am
by wriedmann
Hello,

since the writing of this posts is very time consuming, please don't expect posts in too short periods.

At the same time, I will prepare a PDF that has not only the same content as these posts, but will be kept updated and enhanced, adding better explanations where needed. An example would be the different behavior of the VO garbage collector and the .NET one: .NET calls always the destructor, whereas in VO you need to register for it with RegisterAxit()

Thank you very much to Chris Pyrgas for pointing this out!

Wolfgang

Errors and fixes - Part 1

Posted: Mon Jul 17, 2017 9:12 pm
by Chris
Hi Wolfgang,

Thanks a lot for posting your experience with porting and for explaining the actions and changes you had to make to your code to compile it in X#. I think such information is very helpful, so others will be also prepared about what they will need to do when they also port their apps.

It is also very rewarding for us devtem members to see that our efforts have paid off, it's great seeing and hearing more and more about VO apps that have been already ported to X#. And yes, we will be further improving the procedure in the coming builds.

Chris

Errors and fixes - Part 1

Posted: Tue Jul 18, 2017 3:35 am
by wriedmann
Hi Chris,

I'm very surprised how you guys have done a such compatible compiler (ok, sometimes the error messages could be better or more precise :) ). The VO language and runtime are very different from other development systems, and they allowed us programmers to be very productive. The .NET environment may have several of these things already (like the garbage collector), but there are a lot of specialities remaining.

My base library may be a good example for very old code (its origins are in the pre-release of VO 1.0 under Windows 3.1) and several constructs that are simply not allowed in a .NET language and even some pieces of code that should never have compiled even in VO.

And I have to say that the major part of adjustments were to make in my base library - the other libraries and the Dictionary Editor needed only very few adjustments. And I have started to use the X# version of the Dictionary Editor in my daily VO development.

Wolfgang

Errors and fixes - Part 1

Posted: Wed Jul 19, 2017 6:03 am
by wriedmann
Hi,

if someone is awaiting the next post: I'm currently working on a (more extensive) version of the first 3 articles in PDF format, and I hope to publish the next article tomorrow, together with the relative PDF version (that contains more background information and will be kept up to date).

Wolfgang

XIDE Support for migration

Posted: Thu Jul 20, 2017 3:05 am
by wriedmann
Hi,

since I need to move my application often, I have added a function to my XIDE plugin: Tools - Copy application folder name.
This function copies the name of the application folder name to the clipboard so you can paste it in the VO xPorter output folder input control.

In the attached zip you will find both the sources (you need to change the references to your own XIDE path if you wish to compile itself) and the executable (simply copy to the XIDEPlugins directory and restart XIDE).

Wolfgang
All times are UTC
Page 1 of 5

Powered by phpBB® Forum Software © phpBB Limited