TOPIC:

Hi Dick,
if you don't use GUI classes or other things, you can use the XSharp.VORddClasses, and then it works that way:Or you can put aat 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.

Hi Dick,

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.

.

Hello Chris, Wolfgang,

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?




Dick

Hi Dick,

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.

.

Hello Chris,

Now I am even more confused.

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.



Dick

Hi Dick,

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

Hi Wolfgang,

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!

.

Hello Chris,

Chris wrote:
I did not say that all XSharp dlls are experimental

I didn't say that either, I wrote "all 6"

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

Hi Dick,

ic2 wrote: Hello Chris,

Chris wrote:
I did not say that all XSharp dlls are experimental

I didn't say that either, I wrote "all 6"

Ah, OK, so your references screenshot referred to the other issue. It also contained 6 references, so I was sure you meant those ones

.

Hi Chris,
yes, you are right.
Maybe we should also specify that there are two groups of "new" class libraries:
- the System Classes and the RDD Classes that are simply evolutions of the current VO libraries, compiled for AnyCPU
- the SQL Classes and the GUI classes that are completely rewritten based on ADO.NET (SQL classes) and Windows Forms (GUI classes), so they may not be 100% compatible to the original transported VO classes. Specially for the GUI classes there should be noted that 3rd party libraries like bBrowser and SEUIXP may be completely rebuilt - don't know about ReportPro.

And I don't know id these libraries are also part of the non-subscriber distribution.

Wolfgang
P.S. IMHO the new, Windows Forms based GUI classes are really interesting, and I don't understand why not more people talks about them

Hi Wolfgang,

We aren't really advertising them yet (the Windows.Forms based VOGUI classes), because they are not bullet proof yet, to be used widely, and they do require a lot of changes in existing code currently, due to the strong typing. But we have thought about improvements in this area and have already found and fixed several things in the last months, and after 2.12 is out, I think we will start pushing more also on this front.

.

Hi Chris,
personally I do think that these GUI classes will be the way to go for new applications for experienced VO developers when developing speed counts.
Developing with Windows Forms and/or WPF the development speed goes down to much - and this is why for example Andreas has opted to develop new individual applications using the (old) GUI classes, even when starting development in X# (and we have some of them in production now).
Using WPF for us has only a sense if the customer is willing to pay for it, but not if money counts.
Wolfgang

Hi Wolfgang,

Is it really? Even after you build a set of base classes that offer the standard needed functionality to your forms etc? I know several VO developers who have created many new apps in Windows.Forms with X# (and even in vulcan!).

I think Windows.Forms is missing those nice basic (data handling) features we have in the GUI classes, but this can be implemented once and reused everywhere..

.

Hi Chris,
there are a lot of things in the VO GUI classes that are working very well: from databinding to a dataserver, pictures and multilingual support.
It would be a lot of work to add all these things to Windows Forms - and why we should spend that time?
One of the most important things that will have to be done for the new GUI classes is the bBrowser....and then ReportPro 2, I think.
I'm using much more the ListView control in the last times, but Andreas prefers the bBrowser.
Wolfgang

wriedmann wrote:
[...]
Maybe we should also specify that there are two groups of "new" class libraries:
- the System Classes and the RDD Classes that are simply evolutions of the current VO libraries, compiled for AnyCPU
[...]

i guess it´s a typo and you meant:

- the System Classes and the RDD Classes that are simply evolutions of the current VO libraries, compiled for x86 only

instead of:

- the System Classes and the RDD Classes that are simply evolutions of the current VO libraries, compiled for AnyCPU

regards
Karl-Heinz

Hi Karl-Heinz,
no, I meant it exactly that way:
XSharp.VORDDClasses.dll and XSharp.VOSystemClasses.dll are AnyCPU.


VORDDClasses.dll and VOSystemClasses.dll are x86.

Wolfgang

Hi Wolfgang,

>> VORDDClasses.dll and VOSystemClasses.dll are x86.

yes, that´s what i meant.

To be honest, the whole thread is a bit confusing

regards
Karl-Heinz