Hello Kees.
The reason is that we have a VO code that is continuously updating several products with many customers, so the conveersion has to be instant (an one day issue). We can not develop in X# seperatelly because then we'd have to lose all curent day to day development.
So the process is developing in VO, exporting current versions to X#, testing etc...
Of course when we will deliver in X# then we will have the ability to use components nativelly...
Successful Conversion to X# 2.5b
- Stavros Spanos
- Posts: 115
- Joined: Thu Nov 12, 2015 4:59 pm
- Location: Greece
- ArneOrtlinghaus
- Posts: 412
- Joined: Tue Nov 10, 2015 7:48 am
- Location: Italy
Re: Successful Conversion to X# 2.5b
A one day issue for porting a VO program to X# is a very short time. I can't imagine that it is possible if I think only at the problems of delivery and installation on client computers: missing Dotnet frameworks, missing dlls, antivirus programs.
But there may be also many programming problems to resolve. If you can already convert 90% of your code automatically without problems in conversion and execution, then it is already a good percentage. And the other 10% will need quite a lot of time having to use some alternative implementations.
So we spent time in making a converter using the VOPorter and an own conversion program that exchanged files and often used code lines. The converter could then convert all code in less than 1 hour and we could test and deliver regularly over 2 years without interrupting development.
Arne
But there may be also many programming problems to resolve. If you can already convert 90% of your code automatically without problems in conversion and execution, then it is already a good percentage. And the other 10% will need quite a lot of time having to use some alternative implementations.
So we spent time in making a converter using the VOPorter and an own conversion program that exchanged files and often used code lines. The converter could then convert all code in less than 1 hour and we could test and deliver regularly over 2 years without interrupting development.
Arne
- Stavros Spanos
- Posts: 115
- Joined: Thu Nov 12, 2015 4:59 pm
- Location: Greece
Re: Successful Conversion to X# 2.5b
Arne, we use directives to the compiler. Like...
#IFDEF __XSHARP__
PostMessage( oControl:Handle(), WM_LBUTTONDOWN, 0, 0 )
PostMessage( oControl:Handle(), WM_LBUTTONUP, 0, 0 )
#ELSE
PostMessage( SELF:Handle(), WM_LBUTTONDOWN, 0, 0 )
PostMessage( SELF:Handle(), WM_LBUTTONUP, 0, 0 )
#ENDIF
So all job is done at VO side and we run in X# after an import that lasts about an hour.
#IFDEF __XSHARP__
PostMessage( oControl:Handle(), WM_LBUTTONDOWN, 0, 0 )
PostMessage( oControl:Handle(), WM_LBUTTONUP, 0, 0 )
#ELSE
PostMessage( SELF:Handle(), WM_LBUTTONDOWN, 0, 0 )
PostMessage( SELF:Handle(), WM_LBUTTONUP, 0, 0 )
#ENDIF
So all job is done at VO side and we run in X# after an import that lasts about an hour.
- ArneOrtlinghaus
- Posts: 412
- Joined: Tue Nov 10, 2015 7:48 am
- Location: Italy
Re: Successful Conversion to X# 2.5b
We did similar preparations also for the substitution of OCX-Controls like Image controls/formatted text controls/Internet Explorer.
We replaced the original controls by custom controls that we inserted into the dialog ressources.
The customer controls then initiated the OCX dynamically and forwarded all method calls to the OCX. This way we could write code with IFDefs to substitute the code without having to change the dialog ressources.
Arne
We replaced the original controls by custom controls that we inserted into the dialog ressources.
The customer controls then initiated the OCX dynamically and forwarded all method calls to the OCX. This way we could write code with IFDefs to substitute the code without having to change the dialog ressources.
Arne