at the start of your program file.
I'm doing this in many places.
Wolfgang
P.S. don't forget to add also XSharp.VOSystemClasses, XSharp.VO and the XSharp runtime to the references.
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
If you get an error on "USING VO", then you have not added any of the standard VOSDK libraries as references. Or you have accidentally added the new X# strongly typed versions of those dlls instead (for those, you would have to use "USING XSharp.VO.SDK").
The reason is that the name of the class in X# is not called anymore "DBserver", but it is now named "VO.DBServer" for the standard VO GUI classes and "XSharp.VO.SDK.DBServer" for the new fully strongly typed classes (still under development).
The reason for this rename, is that we do not work anymore in the small VO environment, but we have to play well with 100s or 1000s other .Net languages and libraries, where it is very easy to have naming conflicts. If you search in the web, you will find plenty classes named DBServer already, so there must be a way to distinguish each from another.
The solution in .Net (and other environments) is to use larger, more descriptive class names and for example the main system window class is named "System.Windows.Forms.Form", the 64bit integer type is named "System.Int64", and following the same patter, the VO-compatible class for managing dbfs is named "VO.DBServer", while the strongly typed version is named "XSharp.VO.SDK.DBServer". You can find other similar named classes by other .Net developers, like "Teco.DBServer", "Oci.DatabaseService.Models.DBServer" and many more, which of course have nothing to do with "our" DBServer. If everybody was just using instead simply "DBServer" for their class names, we would end up having conflicts impossible to resolve. The dots inside the names are used by convention, class names could have also been named simply "SystemWindowsFormsForm" or "VODBServer", but
using the dots inside the names makes them more readable.
So that's the reason why you need to use "VO.DBServer". But, because it is tiresome to write "System.Windows.Forms.Form" or "VO.DBServer" etc all the time, the .Net compilers offer a "shortcut", they let you specify the first part of the class name (which is by convention called the "namespace" part) in a USING statement, and then you can address the type simply by the last part of its name. X# goes one step further, it provides a compiler option to tell the compiler to automatically add (transparently to the programmer) such USING statements, when using libraries compiled in X# (such like the X# versions of the VOSDK), to make things even easier. So that's why you need to either enable that project option, or provide the necessary USING VO statements manually.
Chris wrote:
If you get an error on "USING VO", then you have not added any of the standard VOSDK libraries as references. Or you have accidentally added the new X# strongly typed versions of those dlls instead (for those, you would have to use "USING XSharp.VO.SDK").
.
Thanks for the detailed explanation.
I didn't include XSharp.VO (as for me it sounded logical that XSharp.VORDDClass would contain dbServer).
With implicit lookup on, the tooltip says:
Public Class XSharp.VO.SDK.dbServer
Location XSharp.VORDDClasses.DLL
With implicit lookup off, indeed a Using xSharp.VO.SDK or the same before any dbServer statement works.
I didn't expect know about VO.SDK.dbServer.
Just using VO.dbserver doesn't work. Which include am I missing for that?
The VO***Classes assemblies (dlls/references), are the standard VO-compatible SDK ones.
The XSharp.VO***Classes assemblies, are the new ones, which are strongly typed and still under development.
So you need to remove the references to the new ones, and add references to the standard ones instead.
When I change my reference as below, I still get XS0246 The type or namespace VO couldn't be found (with implicit lookup off) on a line like Protect MyDBF As VO.dbserver.
Plus that I didn't realize that 6 of the X# DLL's are actually experimental.
I did not say that all XSharp dlls are experimental, I said that the files with this pattern ("VO*Classes") in their filenames are the new experimental (or still under development if you prefer) typed versions of the VOSDK libraries.
About the code with the PROTECT, this is valid and should compile with no errors. Maybe the error is pointing to something else?
Hi Dick, hi Chris,
I'm using these DLLs regularly in my WPF applications and Windows services without any issue (of course production software for several customers).
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Indeed, the "new" RDD classes are absolutely fine, but the GUI classes are not yet ready to be used widely. Also in the RDD classes, because of the strong typing, code that has inherited classes like DBServer etc will probably need adjustments to run with the new classes, so it's better to use the standard classes first, and after making sure all is working as expected, make the jump to the new ones.
But for completely new code, I agree the new RDD classes are perfect!
Chris wrote:
I did not say that all XSharp dlls are experimental
I didn't say that either, I wrote "all 6" B)
Chris wrote:
About the code with the PROTECT, this is valid and should compile with no errors. Maybe the error is pointing to something else?
As almost always you were absolutely correct. I started writing that I was rebuilding an existing (WCF) project within the same solution with the objective to get rid of WCF and replace it with direct MySQL calls.
Turned out that I made some reference changes in the original project. And then being surprised that the project I was actually working on did still give an error.....
Anyhow, good to now know more about the XSharp.VO DLL's, what the implicit lookup is actually doing (I will surely use that but I wanted to know what I was doing) and more; thanks for all the info.
Dick
