Hi, Development Team
I've always had a question.
Both from the templates provided in previous versions and from my own personal learning experience, I can use the functions in the Core dialect in a project that is set to the Foxpro dialect.
For content in other dialects, e.g., VO dialect functions or classes, I suspect this should be the case as well. This may require adding references to other dialect runtime libraries to the project.
Is that really the truth?
Doubts about "dialects"
Doubts about "dialects"
简单的东西重复做,你能成为专家;重复的东西用心做,你能成为赢家!
Re: Doubts about "dialects"
Hi Xinjie,
you have to separate 3 different things:
- the dialect changes the compiler behavior to mimic some xbase languages syntax. So using the Foxpro dialect the compiler "understands" things that only VFP supported. The Core dialect is basically C# with xbase syntax and does not needs any specific runtime library
- X# applications are running in the .NET environment, and can use all of the classes and methods of the .NET Framework. That does not depends on the dialect. In fact, before the X# runtime libraries were available, I have uses X# to build .NET Framework based applications
- the X# runtime libraries give you commands, functions, datatypes and classes you have used in VFP (or other xbase languages like Visual Objects). DBF support for example is one of the things that only the X# runtime libraries have.
So you can use X#:
- in Core dialect, without using any X# library and any xbase datatype like date or codeblock or array, using "only" what the .NET Frameworks offers
- in VFP dialect, using only what you know from VFP (commands, DBF access and so forth)
- or you can mix them, using both VFP functionalities and .NET Framework functionalities
Most people here are using the last possibility, mainly using the VO dialect and both the relative classes and the .NET Framework classes.
Only a few users (like me) have also plain X# Core dialect applications using nothing from the xbase world other than the syntax.
Wolfgang
you have to separate 3 different things:
- the dialect changes the compiler behavior to mimic some xbase languages syntax. So using the Foxpro dialect the compiler "understands" things that only VFP supported. The Core dialect is basically C# with xbase syntax and does not needs any specific runtime library
- X# applications are running in the .NET environment, and can use all of the classes and methods of the .NET Framework. That does not depends on the dialect. In fact, before the X# runtime libraries were available, I have uses X# to build .NET Framework based applications
- the X# runtime libraries give you commands, functions, datatypes and classes you have used in VFP (or other xbase languages like Visual Objects). DBF support for example is one of the things that only the X# runtime libraries have.
So you can use X#:
- in Core dialect, without using any X# library and any xbase datatype like date or codeblock or array, using "only" what the .NET Frameworks offers
- in VFP dialect, using only what you know from VFP (commands, DBF access and so forth)
- or you can mix them, using both VFP functionalities and .NET Framework functionalities
Most people here are using the last possibility, mainly using the VO dialect and both the relative classes and the .NET Framework classes.
Only a few users (like me) have also plain X# Core dialect applications using nothing from the xbase world other than the syntax.
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
Re: Doubts about "dialects"
Wolfgang,
i think, what he really asks is: Can you set "Foxpro" as dialect AND use things defined e.g. in XBase++ dialect in the same app? Surely it will need to load the corresponding references, but how to tell the compiler to "understand" Fox AND XBase++ ( or any other dialect) ?
i think, what he really asks is: Can you set "Foxpro" as dialect AND use things defined e.g. in XBase++ dialect in the same app? Surely it will need to load the corresponding references, but how to tell the compiler to "understand" Fox AND XBase++ ( or any other dialect) ?
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Re: Doubts about "dialects"
Hi Karl,
as far as I had understand he asked if he could use the VFP dialect and use the functionalities of the Core dialect - that means the .NET Framework.
But you can use all functions of the runtime in all dialects except the Core dialect (that does not knows about arrays, floats, dates and codeblocks).
Wolfgang
as far as I had understand he asked if he could use the VFP dialect and use the functionalities of the Core dialect - that means the .NET Framework.
But you can use all functions of the runtime in all dialects except the Core dialect (that does not knows about arrays, floats, dates and codeblocks).
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
Re: Doubts about "dialects"
HI, Wolfgang and Karl
Thank's all.
I'm not sure how to accurately describe my problem.
An example : CFtp Class
Can I use it in a project that is set to a Foxpro dialect? How ? Just need to add a reference to VOInternetClasses.dll?
I'm very unsure if this is possible. Or rather, I haven't understood X# .
In this sense, Karl understands it more accurately.
Thank's all.
I'm not sure how to accurately describe my problem.
An example : CFtp Class
Can I use it in a project that is set to a Foxpro dialect? How ? Just need to add a reference to VOInternetClasses.dll?
I'm very unsure if this is possible. Or rather, I haven't understood X# .
In this sense, Karl understands it more accurately.
简单的东西重复做,你能成为专家;重复的东西用心做,你能成为赢家!
Re: Doubts about "dialects"
Xinje,
so i understood you correctly.
cFTP is part of Vo assembly, which you may add in references for sure and it should work.
But i never tried this, maybe there are some corner cases, where some of the "tweaks" to the compiler via the dialect switches might interfere with each other.
I'd simply try it
- and surely later in the day one of the dev guys will jump in to enlighten us
so i understood you correctly.
cFTP is part of Vo assembly, which you may add in references for sure and it should work.
But i never tried this, maybe there are some corner cases, where some of the "tweaks" to the compiler via the dialect switches might interfere with each other.
I'd simply try it
- and surely later in the day one of the dev guys will jump in to enlighten us
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Re: Doubts about "dialects"
Guys,
Yes, it should be possible to use classes from VOInternetClasses.dll in a VFP dialect app, I don't think this library depends on anything that's specific to the VO dialect, so it should be no problem.
But I think there's no reason to do this. This library is provided simply for compatibility with VO, so VO developers who have used the VO internet classes can port their VO apps to X#, without needing to modify that part of the code. But this library is also written like 20-30 years ago and is probably quite outdated, so I think it's much better to instead use the classes the .Net Framework has to offer.
Here's the documentation about the System.Net.FtpWebRequest class (it's included in System.dll) that can be used for that: https://learn.microsoft.com/en-us/dotne ... work-4.8.1
Yes, it should be possible to use classes from VOInternetClasses.dll in a VFP dialect app, I don't think this library depends on anything that's specific to the VO dialect, so it should be no problem.
But I think there's no reason to do this. This library is provided simply for compatibility with VO, so VO developers who have used the VO internet classes can port their VO apps to X#, without needing to modify that part of the code. But this library is also written like 20-30 years ago and is probably quite outdated, so I think it's much better to instead use the classes the .Net Framework has to offer.
Here's the documentation about the System.Net.FtpWebRequest class (it's included in System.dll) that can be used for that: https://learn.microsoft.com/en-us/dotne ... work-4.8.1
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Re: Doubts about "dialects"
Guys,
What a very good question, and also some very good answers.
In addition to what Chris already said (and I agree about FtpWebRequest):
- The dialect of a project controls the behavior of the compiler. For example:
x Setting the FoxPro dialect enables the FoxPro "DEFINE CLASS" syntax and some other FoxPro specific language constructs.
If you look in the Parser definition, you can see that some parser rules are prefixed with {IsFox}?
https://github.com/X-Sharp/XSharpPublic ... /XSharp.g4
The compiler also uses the "foxsource" rule as entry point, to allow for statements at the start of the file before the first function/procedure/class
x Setting the VO dialect enables VO specific rules, like the VO structure and Union. The same file contains {IsVO}?
x The compiler dialect also tells the compiler which runtime DLLs are mandatory (for example, FoxPro classes can inherit from a FoxPro specific parent class).
This DLL also contains the code for the FoxPro specific handling for the WITH .. ENDWITH statement and to decide at runtime if Foo(1,2) is a function call
or if this references a public array variable with the name "Foo". See below.
x The compiler automatically defines the define __DIALECT_FOXPRO__ or __DIALECT_VO__ etc. based on the chosen dialect.
This is used to control which header files for UDCs are used. In the XSharpDefs.xh you can find constructs like
#ifdef __DIALECT_FOXPRO__
#include "FoxProCmd.xh"
#endif
Also, the rule for TEXT ENDTEXT has a "common" implementation inside XSharpDefs.xh and a FoxPro specific implementation in the FoxPro header file.
The common rule is in a section that starts with #ifndef __DIALECT_FOXPRO__
- The FoxPro runtime DLL (XSharp.VFP.DLL) contains some of the "compiler support" functions and implementations of FoxPro runtime functions that do not exist or behave differently in other dialects.
The file https://github.com/X-Sharp/XSharpPublic ... upport.prg has an Init procedure that
takes care of some of this. FoxPro also allows to update DBF files in shared mode without manual locking. Inside this file you can see that
an "AutoLock" and "AutoUnLock" function are registered inside the runtimestate.
You can also see some functions with names that start with "__". These are used by the compiler to implement specific features for the FoxPro dialect.
Now the VOInternetclasses DLL that you were referring to in your original question are compiled with the VO dialect. However, the code in there is compiled into normal .Net code, and can be used from any language, so also from X# in the VFP dialect, but also from C# and VB.
There are a few things to remember:
- In general, you should also include links to the DLLs that this depends on. These are XSharp.VO, VOSystemClasses, VOWin32APILibrary
- This DLL is compiled in x86 mode. So your VFP code should also be compiled in x86 mode. The reason for this is that on several places in the code Pointers and 32 bits numbers are "mixed". This is not ideal, but that was the case in Visual Objects, and we did not want to change the code
Robert
What a very good question, and also some very good answers.
In addition to what Chris already said (and I agree about FtpWebRequest):
- The dialect of a project controls the behavior of the compiler. For example:
x Setting the FoxPro dialect enables the FoxPro "DEFINE CLASS" syntax and some other FoxPro specific language constructs.
If you look in the Parser definition, you can see that some parser rules are prefixed with {IsFox}?
https://github.com/X-Sharp/XSharpPublic ... /XSharp.g4
The compiler also uses the "foxsource" rule as entry point, to allow for statements at the start of the file before the first function/procedure/class
x Setting the VO dialect enables VO specific rules, like the VO structure and Union. The same file contains {IsVO}?
x The compiler dialect also tells the compiler which runtime DLLs are mandatory (for example, FoxPro classes can inherit from a FoxPro specific parent class).
This DLL also contains the code for the FoxPro specific handling for the WITH .. ENDWITH statement and to decide at runtime if Foo(1,2) is a function call
or if this references a public array variable with the name "Foo". See below.
x The compiler automatically defines the define __DIALECT_FOXPRO__ or __DIALECT_VO__ etc. based on the chosen dialect.
This is used to control which header files for UDCs are used. In the XSharpDefs.xh you can find constructs like
#ifdef __DIALECT_FOXPRO__
#include "FoxProCmd.xh"
#endif
Also, the rule for TEXT ENDTEXT has a "common" implementation inside XSharpDefs.xh and a FoxPro specific implementation in the FoxPro header file.
The common rule is in a section that starts with #ifndef __DIALECT_FOXPRO__
- The FoxPro runtime DLL (XSharp.VFP.DLL) contains some of the "compiler support" functions and implementations of FoxPro runtime functions that do not exist or behave differently in other dialects.
The file https://github.com/X-Sharp/XSharpPublic ... upport.prg has an Init procedure that
takes care of some of this. FoxPro also allows to update DBF files in shared mode without manual locking. Inside this file you can see that
an "AutoLock" and "AutoUnLock" function are registered inside the runtimestate.
You can also see some functions with names that start with "__". These are used by the compiler to implement specific features for the FoxPro dialect.
Now the VOInternetclasses DLL that you were referring to in your original question are compiled with the VO dialect. However, the code in there is compiled into normal .Net code, and can be used from any language, so also from X# in the VFP dialect, but also from C# and VB.
There are a few things to remember:
- In general, you should also include links to the DLLs that this depends on. These are XSharp.VO, VOSystemClasses, VOWin32APILibrary
- This DLL is compiled in x86 mode. So your VFP code should also be compiled in x86 mode. The reason for this is that on several places in the code Pointers and 32 bits numbers are "mixed". This is not ideal, but that was the case in Visual Objects, and we did not want to change the code
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
Re: Doubts about "dialects"
Guys,
Would it be a good idea to do an online session about this?
We have not done online sessions in a while, and I think this subject "the differences between X# dialects" is a great session for an online presentation.
Robert
Would it be a good idea to do an online session about this?
We have not done online sessions in a while, and I think this subject "the differences between X# dialects" is a great session for an online presentation.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu