xsharp.eu

Hi Tom,

tom@dieselworks.com.au wrote: This helps a lot, and I guess will other newcomers too. You guys certainly helped to clear up a few things but now I have a new question: What should I do? Should I start trying to convert one of my apps? or wait ? what can I convert, and what not? actually the NOT is what I like to know!
Also I have no Vulcan, so what are my choices?

There is NOTHING that you cannot convert, provided you take on the .NET way of doing things.

Since you don't have Vulcan, you cannot use yet any VO specifics, e.g. DBF, Graphics4VO, bBrowser and VO functions.

I would suggest starting by creating a .NET Forms application and build the menu/toolstrip from your VO app. Use the MenuStrip and ToolSttrip for doing that. You can use the Form Builder in XIDE for this. Then build a View for some data, can be anything since we not going to bind the data yet. Simple form with a DataGridView (bBrowser) alternative.

Once you there, use a simple Access database and let us know, then we can take you from there to populate your view with a table from the Access database or any other RDBMS of your choice. DBF will have to wait till around Sept if I am not misttaken.

HTH,

Hi Tom,

since you have no Vulcan license, you have not any copy of the VO class libraries that compiles in X#.

So to start converting your VO applications you have to wait until the tool that converts your VO class libraries to X# is available.
Currently AFAIK there was no date given for that, but I suspect this may be shortly after the final release of the runtime.

What you can do now, are a few other thing: write new tools and utilities in X#, so you familiarize with it and with its concepts, and you can write COM libraries für your VO applications.

You have only SQL applications, so you don't need to wait for the RDDs as many of us will do.

Wolfgang

P.S. I have already written a X# WPF application that is in production for 2 years now, using the Core dialect and no VO functionality. And several of my VO applications use COM libraries written in X# for functionalities not available in VO.
And since I own a Vulcan license, I'm at a good point in the migration of my VO applications. Some of them work already, but are not yet in production.

Hi Tom,

another thing: the public release of X# 2.0 beta 2 is available - if you install it and add the X# runtime to your application, the VO functions will be available to you.

Wolfgang

Hi Tom
We all think differently. My advice would be “Think in real Terms”.

You may well prefer to think in Business Procedural Terms, but I prefer to “Think Aircraft” so please bear with me.

Aircraft have to be built.
Aircraft have to be flown.

They, except for things like Harrier, can only fly forward, and although they can fly around in circles and back to a previous position, they nor anything else in the real world, can go back in time.
Aircraft are everywhere. They must be kept apart, and once they’ve left their airfield, they’re free to move up, down, left or right and accelerate or decelerate in any of them. Their movement can be considered as having 6 degrees of freedom.

It is not until they’re flown that they are of any practical use: nor is a computer program. The following, very superficial aircraft analogy can be carried forward to most things you will encounter in the future.

Let’s start off with building.
You are building Concorde.
I am building an F135.
Both consist of lots of similar bits and pieces that either of us can use; all we need do is scale them a bit and bolt them together.

You get your Concorde built; it flies OK great success.
My F135 gets airborne OK flies around a bit then crashes.

What is the difference? Everything has been done the same way. For every error in the Concorde build there will.an identical error in the F135 build. So how come Concorde did not crash?
Clearly there is a bug in the build instructions. Perhaps the altimeter, being physically round, has been mounted upside down
In the case of both aircraft, the pilots notice this and take account of it when poling around.
But in the case of the F135 it pulls so much g that the pilot blacks out, control is switched to the auto-pilot which reacts with pure logic!

The solution is to properly “key” the altimeter in the design stage so that it cannot be mounted upside down.
As far as application development is concerned you will be doing much the same thing: standard OOP stuff to ensure that there can be no upside-down altimeters when it comes to assembly thus subsequent action can be hived off to an automated auto-pilot procedure without further thought.

I hope that helps to paint some “picture” in your mind of what is going on. I hope too that this mish-mash of metaphors and analogies makes sense.
I truly believe that the sooner folk get some real-world analogy in their mind, the easier their learning curve will be.

Now to the practical side. Take Johan’s advice and give a Forms application a go.
Then, as Wolfgang says, you’ll have to wait for XSharp conversion tools, so try a bit of WPF in C#.
Most of the initial set-up code will be generated for you automatically and you’ll almost certainly need a bit of WPF in the future anyway.

Generate a new WPF (Net Framework) app.
Then use Solution Explorer to add a Class Library (Net Framework)
Your aim is to get controls on the .Net Framework App to activate something in the library. Say bring up a window.
WPF is far too extensive to go into in much depth here. Basically it adapts the size of its controls to the size of the screen area that is available to it. Thus, if you try to put a button on a window it will assume it has the full window area available and fill the window with one control.
Therefore you have to have some intermediate host for your controls.
Try adding a button to your main window (using say a Stack Panel as host) which does something in a window of of your subsidiary class library. Add it to the code behind.
public MainWindow()
{
InitializeComponent();

StackPanel sp = new StackPanel();
Button btn1 = new Button();
btn1.Content = "Show Window 1";
btn1.Click += Btn1_Click;
sp.Children.Add(btn1);

Button btn2 = new Button();
btn2.Content = "Change Window 1 Background";
btn2.Click += Btn2_Click;
sp.Children.Add(btn2);


this.Content = sp;
}

Look at all the references that have been added automatically to main App. Compare with those added generated for the library – there will be substantially fewer. In particular the references needed for window generation will not be there. So, you need to add them. Things like presentation core, windows base.
Once your library compiles you have to link things up across the projects in your solution – add a using statement to the library in MainWindow.xaml.cs and you’ll be able to call across directly.
Examine all the references and you’ll soon see how things link up. Trying to link things that could cause a problem later will not be allowed – probably flagged up as a “circular reference”, which in the aircraft analogy means going backwards in time.
You may find a few things that are new to you – XAML for example, but explanation of all that can come later. Phil’s Click Start docs cover all that in detail.
Sorry if this is a bit sketchy, but hope it helps.
Terry

Hello Terry,

Terry wrote:Hi Tom
We can give each namespace a name and that allows us to spread its code over a file structure of our own choosing.
VS then allows us to change names etc so they reflect our thinking.

You wrote an interesting observation. You mention the above which is I think the contrary: one of the -many- weak points of VS. When you create a new WPF program in VS it will always give it a standard name regardless of what you've chosen on creating the solution. In an attempt to rename it to something meaningful you have to dig deep in the swamp of VS hidden files where the default name has been stored as a kind of virus. The most basic tasks in VS require an absurd amount of time to correct as hardly anything works as one would expect. Changing names is a good sample.

Dick

Hi Dick

Yes you are right. But I do not agree that you have to dig too far to make meaningful changes.

VS offers a host of re-factoring capabilities name changing being one. If it can do it safely over the assembly it will.

Namespace name changes may well affect other assemblies, but you can do a solution wide name change if sufficiently confident in what you're doing and re-compile - 10secs? - and the build process will flag up errors. Easy to track down.

If you aren't confident with solution wide changes, do it piecemeal one assembly at a time.

My point was: you can do all these things. Just how, in this context, is for later and to some extent solution dependent. It is, I agree, more difficult to get round MS defaults in the main exe, but once out into the libraries there are fewer restrictions.

I like VS, but that is purely from a personal point of view.

Best Regards

Terry

Thanks Guys, I am doing my best but these concepts are still confusing me. I know, I just have to get over the first major hurdle and will be fine. Once it clicks it will be easier
thanks for all the support
Tom

Hello Terry,

But I do not agree that you have to dig too far to make meaningful changes.
VS offers a host of re-factoring capabilities name changing being one. If it can do it safely over the assembly it will.

I know I am extreme negative about VS compared to almost everyone here. But the more I use VS, the more it proves me right. I mean: why do I have to manually change a namespace in multiple files including obscure files VS apparently needs to support it's solutions? If VS would give my namespace the name I defined on starting the project in the first place, and took care of changing a namespace itself wherever it is needed when I change it in the editor, I would have 2 reasons less to hate VS. If you install VS your HD is filled with millions of files adding up to many, many Gb's. I wonder what all this is doing? Xide is 3,63 Megabyte and 79 files is a pretty complete editor and compiler. For the amount of files and diskspace VS uses I would expect it would do the full programming for me at least.

Dick

Hi Dick,

XIDE is very, very small compared to VS because it is the (excellent) work of single person, and not of a large group of people in more than 20 years.
And XIDE has only a fraction of the functionality of Visual Studio.
There is no WPF editor and no HTML editor in XIDE, and many more things.

I would call XIDE more focused and I prefer it over Visual Studio.

Wolfgang

ic2 wrote:took care of changing a namespace itself wherever it is needed when I change it in the editor

That's the price for not having a repo . AFAIS, they use filebased metadata with all inherent risks for mangling things. That's why someone invented databases for this job, meanwhile there'd exist some which never corrupt data <vbg>.
On a serious note: personally i fear this thousands and thousands of files - no one will ever convince me that someone has a solid understanding what they all do and how they interfere...