xsharp.eu

Hi Michael,

even if I'm not Phil, and not one of the VO or X# "gurus", I'll try to answer your questions from the standpoint of a longtime VO developer.

1) There is nothing like a unique DBServer object that takes care of all. In fact, SLQ database servers are much more powerful and at the same time much more complex than a simple DBF table. So be prepared to work with several classes that have different functions. For example, there are ConnectionStringBuilder classes that help you to construct a connection string, and you are not forced anymore to write it by hand like in the VO SQL classes.

2) I don't know the possibilities of Visual Studio to design your SQL database structure, but of course there are visual tools to build your databases, and for some you can spend a lot of money. Personally I'm using Navicat Premium Essentials as I have several SQL databases to maintain (from MySQL to MS SQL, Oracle to SQLite)

3) X# is a new language built on the Vulcan syntax and Vulcan was built on the VO syntax - like VO was built on the Clipper syntax. VO has introduced a lot of new language features over Clipper, and so Vulcan has added new language elements over VO, and X# has added even more. You don't need to use them all, but the more you explore the possibilities of the language, the more you will need (and understand) them.
"local implied" is a local variable which type is "implied", i.e. the compiler knows what type it is and so you can save time to write the "as" clause. Personally I have decided to not use it as I feel code is harder to read.

4) If you have decided for WPF, you have decided for a lot of frustrations and really a lot of fun. The concept of WPF is more like HTML and less than Windows API/GUI. Is is very dynamic, and IMHO a graphical editor will never been able to accomplish what you can do (the same is true for HTML). So if you decide to use WPF, most likely you have to learn also XAML (I have decided to write my WPF code by hand, but I think it is the harder way). Any way, WPF takes the binding concept we know from VO's DataWindow much, much further.

In your message, I'm missing a 5) point: MVVM. If you use WPF without MVVM, you will miss a lot.

When it comes to MVVM, personally I have found only a few books that really helped me. Some time ago, I have tried to build a list of books that helped me:

https://www.riedmann.it/blog/?p=168

It took me more than two years to understand the most important concepts of this entire new world, and I have to confess that I'm far from understanding it all. My first WPF/MVVM software is about to go in production next week - it took months more than planned.

But if you are willing to take this adventure, you will discover a new fun of programming!

Wolfgang

Michael,

"local implied" is a local variable which type is "implied", i.e. the compiler knows what type it is and so you can save time to write the "as" clause. Personally I have decided to not use it as I feel code is harder to read.

FWIW, with X# there's another, imho, better version: "var" - meaning the same as "local implied", but a lot shorter If, unlike Wolfgang, you want to use it, this is the way to go. Have a look in the X# help for some samples of use.

Re placing of declarations: yes, you are now allowed to declare whereever you want, obviously as long as it is "before" the use...Not sure, if i hold this "better".
Along with this now we also have "scoped" variables, so you might "reuse" names in an entity - this i do not

Hi Phil, Wolfgang & Karl,

thanks for all your answers. I was somewhat frustrated yesterday and based on Wolfgang's post I still have hope.

MVVM - never heard about it. Something new - I like that

As promised to Phil I am committed to learn.

Question to you all: If I have questions (as stupid as they might be) do you like me to bundle them or post them as they pop up?

Cheers
Michael

Michael,

Whatever suits you - probably more and shorter would suit me, and then some Q's don't get overlooked.

Just don't give up, you have come a long way, and things are about to get easier. I will soon have the five table version of the demo app (L2S), we have been studying, ready for posting and your testing. Button clicks show different Table returned data sets.

Then we can move on to see EF6 (entity framework vn.6) in action - we will define an 'ORM' in code and then let the system make us a database - as easy as that. (ORM = Object Relational Mapping)

Here is a working screen shot - four instances of the demo app running together, just to show the different table data :-
[Each button click fills the data grid with different data, hence different columns.]
Keep on smiling,
Regards,
Phil.
Wales, UK.

Hi Michael,

personally I would prefer that you post your questions whenever they pop up....

If I remember the migration from Clipper to VO: it were two years full of frustrations, partially because VO in the first versions was very unstable, but for the most about the new concepts introduced, like object orientation, GUI, notification based OS, ....

Now, about 20 years later, I'm of course 20 years older, and learning is not so easy with 54 years as it was with about 30 years, and I'm much more under pressure as customers are less patient and I have much, much more code in VO than in Clipper (totally it should be over 2,5 millions of lines). And another important fact: not only my expectations are much higher than 20 years ago, but also the expectations of my customers.

I'm convinced that X# and WPF is the only way to go. Add SQL (I'm use SQL in my VO applications too, but not as main data storage) and MVVM, and you will have a lot to learn.

But I repeat: playing and working with X# is fun, and slowly you will understand how .NET works. Years ago we saw the Windows API as very big toolbox, but the .NET framework is much larger.

Sometimes the lot of different classes is very confusing, specially because there are several classes that seem to be duplicated, but with .NET some things that were hard or impossible with VO are easily to accomplish.

Please don't expect fast results, and take the time to understand what you are doing. The results will show you that the invested time was a good investion. (I had more than one moment when I was so frustrated that I was about to uninstall all the .NET tools from my disk, and the hardest was when I felt totally stupid, below the level of a beginner).

But now the hardest time for me is past, I hope it at least. And it is really funny to work with X#, and I cannot await the moment when my most important VO applications are migrated to X# and I can continue my development there.

Wolfgang

P.S. Basically, this message should be a "heads up" for you, and a "don't give up!"

For "many" small questions i' prefer the Newsgroup, simply because it is faster.

To follow Phil, i'm hampered by the hardcoded MS SQL, i'm with Postgres - maybe we could make Phil and Johan join their efforts?

Hi Karl,

I for myself would prefer the NG, but the forum messages are more visible and give more layouting possibilities, so I would opt for the forum.

Wolfgang

P.S. since today morning, the forum notifications don't come in anymore

Okay guys,

For those interested here is a link to my OneDrive folder which has folder / file details for the full five table demo app we have been following :-

https://1drv.ms/f/s!AiCBl-gBWjY9g_kVSq0FLG5QCt872Q

See if you can download the solution and run it in your Virtual machine.

Click the buttons in any order you choose.

Oh! - this app is based on a simple pattern of development - no MVVM approach, but definitely Data Binding being used in a simple/direct fashion.
Good Luck and keep me informed please.
Phil.
Wales, UK.

Hi Michael,

personally for questions not related this thread I would use a new forum thread and not continue this one.

Wolfgang

Hi Karl,

I am not an expert in matters SQL when it is outside my MS use and experimentation with MSSS.

However, I think I am right in thinking that for 'well known' and established SQL 'other flavours' there is no problem or issue to doing what I will do with Entity Framework. (L2S is different, it may be more limited to MS, but we are moving on ...).

There will be a 'factory' to provide a connection string, and the beauty of LINQ is that it is agnostic to the backend SQL engine. All you need is the provided 'driver' software, and the underlying 'system' does the rest for us.

Because in LINQ we do not code in T-SQL - so our .NET code is usable by many 'makes' of SQL engine. LINQ is for processing .NET collections. We just need the SQL 'driver' as such.

Give me a short while to finish off my picture frame (wood work in progress) and then we can look at using EF6 and making a SQL database with just a short line of code, once our .NET classes for entities are defined. This is way, Way, WAY, better than the older ADO.NET approach we used to use in .NET ;-0)

We also don't need to worry about data types in the SQL database tables - we just define our .NET class code, simple !

Regards,
Phil.