Hi XSharp developers team,
I would love to see some material to help new comers to X#. How can a user start converting his/her VO project to X#...
Help and Support system of any software or language decide its future growth, popularity etc. ...
Hope to see some help regarding the issue
Visual Objects to X# (Project Conversion)
Visual Objects to X# (Project Conversion)
Dasanudas,
We are working very hard to add support for the xBase datatypes, runtime and classes.
Once we have that ready then the VO compatibility will be possible.
At that moment we will also come with examples and an XPorter tool with which you can export Visual Objects projects to a X# solution and then continue to work in X# and extend your application in DotNet.
We will not have 100% compatibility, I can assure you that. Visual Objects allows things that will never work in DotNet, such as adding methods to classes defined in another class library (such as the App:Start() method that is almost every GUI application).
For security DotNet does not allow you to add methods to somebody else his code.
We will come with examples and solutions for these problems.
Robert
We are working very hard to add support for the xBase datatypes, runtime and classes.
Once we have that ready then the VO compatibility will be possible.
At that moment we will also come with examples and an XPorter tool with which you can export Visual Objects projects to a X# solution and then continue to work in X# and extend your application in DotNet.
We will not have 100% compatibility, I can assure you that. Visual Objects allows things that will never work in DotNet, such as adding methods to classes defined in another class library (such as the App:Start() method that is almost every GUI application).
For security DotNet does not allow you to add methods to somebody else his code.
We will come with examples and solutions for these problems.
Robert
DasaAnudas wrote:Hi XSharp developers team,
I would love to see some material to help new comers to X#. How can a user start converting his/her VO project to X#...
Help and Support system of any software or language decide its future growth, popularity etc. ...
Hope to see some help regarding the issue
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
-
Frank Maraite
- Posts: 176
- Joined: Sat Dec 05, 2015 10:44 am
- Location: Germany
Visual Objects to X# (Project Conversion)
Hi DasaAnudas,
I'm not member of DevTeam but have a lot ecperiences to do this task.
There are to things:
1) go to the .NET world
2) go to X#
Why do I point this out: Robert announced X# beeing VO compatibel for later this year. So you could wait or prepare yourself meanwhile.
But it will be a good idea to prepare in VO first, especially the typing. Since USUALS are unknown in the .NET world, they will be in X# later, not now. So for now you can only use the original .NET types. When you use USUALS later in X#, you cannot give them to any other .NET library. So you should eleminate them then.
So what to do now: Start with strong typing and killing all usuage of USUALS, FLOAT etc. right now in VO. The more you do now the less you have to do later. At one time you have to do that. Only if you like to stay in X# only world you don't need, because X# will support these. But you will see, that you want to interact heavily with other subsystems too.
A good starting point maybe: select some of your GUI less base libraries, the basic functions or so, and copy them to an X# project and try to translate. You see all the places, where these special types are used. Then do the changes in VO. Then introduce yourself to untit testing very quickly. Use the time for learning exiting things that are possible in .NET until Robert is ready.
I began this process a few years ago. I had it Vulcan runtime free since about three years and running as 64bit. Now I have my first application in X# with more than 100.000 lines of code running smoothly. With thousands of little tests I could prove that the comiler not only say: 'Compilation successful', but also that the results of compilation are correct as they were in Vulcan. It's great to see that and makes yourself confident to the product.
The next thing you have to do is to separate your business code from your GUI. You want at some time use WPF or other .NET GUI instead of VO compatible GUI. But here I cannot say more on how Robert will adopt the GUI. Maybe it will be tricky.
As I understand the roadmap correctly, you will be able to go from VO to X# later this year with no or only minor changes. But this is only a delay for the things I mentioned above.
Frank
I'm not member of DevTeam but have a lot ecperiences to do this task.
There are to things:
1) go to the .NET world
2) go to X#
Why do I point this out: Robert announced X# beeing VO compatibel for later this year. So you could wait or prepare yourself meanwhile.
But it will be a good idea to prepare in VO first, especially the typing. Since USUALS are unknown in the .NET world, they will be in X# later, not now. So for now you can only use the original .NET types. When you use USUALS later in X#, you cannot give them to any other .NET library. So you should eleminate them then.
So what to do now: Start with strong typing and killing all usuage of USUALS, FLOAT etc. right now in VO. The more you do now the less you have to do later. At one time you have to do that. Only if you like to stay in X# only world you don't need, because X# will support these. But you will see, that you want to interact heavily with other subsystems too.
A good starting point maybe: select some of your GUI less base libraries, the basic functions or so, and copy them to an X# project and try to translate. You see all the places, where these special types are used. Then do the changes in VO. Then introduce yourself to untit testing very quickly. Use the time for learning exiting things that are possible in .NET until Robert is ready.
I began this process a few years ago. I had it Vulcan runtime free since about three years and running as 64bit. Now I have my first application in X# with more than 100.000 lines of code running smoothly. With thousands of little tests I could prove that the comiler not only say: 'Compilation successful', but also that the results of compilation are correct as they were in Vulcan. It's great to see that and makes yourself confident to the product.
The next thing you have to do is to separate your business code from your GUI. You want at some time use WPF or other .NET GUI instead of VO compatible GUI. But here I cannot say more on how Robert will adopt the GUI. Maybe it will be tricky.
As I understand the roadmap correctly, you will be able to go from VO to X# later this year with no or only minor changes. But this is only a delay for the things I mentioned above.
Frank
Visual Objects to X# (Project Conversion)
Hi
just a little question. what is a usual type variable ?
i do like
LOCAL odbServerNew AS _cryptServer
LOCAL cFile AS STRING
LOCAL cTempfile AS STRING
LOCAL nRecno2 AS DWORD
and float for float
So i dont understand, what i have to change.
Horst
just a little question. what is a usual type variable ?
i do like
LOCAL odbServerNew AS _cryptServer
LOCAL cFile AS STRING
LOCAL cTempfile AS STRING
LOCAL nRecno2 AS DWORD
and float for float
So i dont understand, what i have to change.
Horst
-
Frank Maraite
- Posts: 176
- Joined: Sat Dec 05, 2015 10:44 am
- Location: Germany
Visual Objects to X# (Project Conversion)
Hi Horst,
you are my friend.
If you miss the type like
LOCAL Var
var is then a USUAL. In can hold all types. That makes it unique to VO and Vulcan.
The VO runtime mostly uses USUALS, look in the help file for that.
A float is also a special type, it contains additional information for formatting. The .NET equivalent is System.Double, but this is identical to REAL8 in X#. REAL8 is also in VO.
If you have completly strongly typed libs, why not try to compile in X#`?
HTH
Frank
you are my friend.
If you miss the type like
LOCAL Var
var is then a USUAL. In can hold all types. That makes it unique to VO and Vulcan.
The VO runtime mostly uses USUALS, look in the help file for that.
A float is also a special type, it contains additional information for formatting. The .NET equivalent is System.Double, but this is identical to REAL8 in X#. REAL8 is also in VO.
If you have completly strongly typed libs, why not try to compile in X#`?
HTH
Frank
Visual Objects to X# (Project Conversion)
So i have no problem because i was making -> as string and so on ?
Only the float has to change to Real8 ?
I like it when the compiler tells me - i pass a Number instead a string. Thats why i made code like that. And somewhere was written, its also faster.
Horst
Only the float has to change to Real8 ?
I like it when the compiler tells me - i pass a Number instead a string. Thats why i made code like that. And somewhere was written, its also faster.
Horst
Visual Objects to X# (Project Conversion)
Hi Horst,
if you are using arrays and codeblocks other than floats, currently you can move your code only when you have also a Vulcan.NET license, because X# at the current state can use the Vulcan.NET runtime. (personally I think arrays and codeblocks are together with the runtime compiler one of the strongest features of VO. With .NET you have lists and collections, and also lambda functions, so for new code you can live with the current X# state).
As the roadmap states, an own runtime for X# is planned for later this year.
Personally I would start immediatly playing with X#, and learning how .NET works. Of course, X# can be used as Clipper and VO, but the full power will be uncovered when you start using the framework itself - it solves really a lot of things VO cannot solve easily, like SMTPS or https.
As example, for a current project I need access to the AdWords API, and with VO it would be nearly impossible to do it, but with X# I can use the interface library written in C# that Google distributes.
Wolfgang
if you are using arrays and codeblocks other than floats, currently you can move your code only when you have also a Vulcan.NET license, because X# at the current state can use the Vulcan.NET runtime. (personally I think arrays and codeblocks are together with the runtime compiler one of the strongest features of VO. With .NET you have lists and collections, and also lambda functions, so for new code you can live with the current X# state).
As the roadmap states, an own runtime for X# is planned for later this year.
Personally I would start immediatly playing with X#, and learning how .NET works. Of course, X# can be used as Clipper and VO, but the full power will be uncovered when you start using the framework itself - it solves really a lot of things VO cannot solve easily, like SMTPS or https.
As example, for a current project I need access to the AdWords API, and with VO it would be nearly impossible to do it, but with X# I can use the interface library written in C# that Google distributes.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Visual Objects to X# (Project Conversion)
I will approach X# as way to create an app that from ground app, not converting an existing one to .NET, but rather re-writing it.
However, I love C# already, but there is an area that I am not comfortable with ADS .NET Data Provider. Hence the need for Vulcan.NET (and lately with X#) due to the the ADS RDD where I can access our DBF data directly with same business rules as the VO counterparts. the area that I have seen X# have great use for solving our problems is data sync between our VO + ADS (DBF) apps to new C# + Postgres apps (MVC5/6).
The timeline that X# roadmap seems to jive with ours. I will looking at this with keen interest.
However, I love C# already, but there is an area that I am not comfortable with ADS .NET Data Provider. Hence the need for Vulcan.NET (and lately with X#) due to the the ADS RDD where I can access our DBF data directly with same business rules as the VO counterparts. the area that I have seen X# have great use for solving our problems is data sync between our VO + ADS (DBF) apps to new C# + Postgres apps (MVC5/6).
The timeline that X# roadmap seems to jive with ours. I will looking at this with keen interest.