fbpx
Welcome, Guest
Username: Password: Remember me
Visual Objects

Please use this forum to post questions about Visual Objects and Vulcan.NET
  • Page:
  • 1
  • 2

TOPIC: X# Core - which way?

X# Core - which way? 8 months 3 weeks ago #1

  • tom@dieselworks.com.au
  • tom@dieselworks.com.au's Avatar Topic Author
  • Offline
  • Posts: 33
Hi All,
Now that I have my little sample app working I need to get into it but I do not want to head the wrong way, so I have a few questions:
Using the X# Core how do I access SQL servers? MS-SQL
Comparing to VO, what are the limitation in respect of capabilities? Classes? Add-ons?
Where do I find a reference of the available functions of X# Core ?
If there is an article related to these please point me there, but any help is appreciated
TIA

Tom

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #2

Tom,
X# core (at this moment) does NOT have any functions. It has only the .Net data types and methods available.
Once our runtime is ready to the general public (it is only available to subscribers at this moment) then you will also be able to use typed functions like Left(), Substr3() etc.

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #3

  • wriedmann
  • wriedmann's Avatar
  • Away
  • Posts: 1436
  • Karma: 6
Hi Tom,

with Core you can use Ado.NET or the Entity Framework.

I use (the old way, I know) the classes in System.Data.SqlClient.

You can use the class SqlConnection to open a connection:
_oConnection := SqlConnection{}
_oConnection:ConnectionString := ConnString
_oConnection:Open()
 _lConnected := self:IsConnectionOpen()

and then retrieve a datatable:
oAdapter := SqlDataAdapter{ cSelect, self:Connection }
oDataSet  := Dataset{}
oAdapter:Fill( oDataSet )
oDataTable := oDataSet:Tables[0]
oDataSet := null_object

or execute a SQL statement:
oCommand := SqlCommand{ cStatement, _oConnection }
nReturn := oCommand:ExecuteNonQuery()

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #4

Hi Wolfgang/Tom and everybody else following,

wriedmann wrote: with Core you can use Ado.NET or the Entity Framework.
I use (the old way, I know) the classes in System.Data.SqlClient.
You can use the class SqlConnection to open a connection:

Not to forget the DbProviderFactories which allow Database agnostic code:
VAR oProvider := System.Data.Common.DbProviderFactories.GetFactory(sProvider)
VAR oConn := oProvider:CreateConnection()
oConn:ConnectionString := sConnection
VAR oComm := oProvider:CreateCommand()
oComm:Connection := oConn
oComm:CommandText := strSql
oConn:Open()
VAR oReader := oComm:ExecuteReader()
Regards,
______________________
Johan Nel
George, South Africa

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #5

Hi Tom

Believe me I do appreciate the difficulties of initially getting to grips with things in the .Net arena. It is vast, but although implementation may be hugely complex, I can assure you that understanding it all is much, much easier.

There are basically only two challenges ahead for anyone, one which you already know, is learning the language syntax, the other is the array/matrix of functions available to you from the .Net Framework which exists on your machine within mscorelib (Multi-Language Standard Common Object Runtime).

The mscorelib array of functions is vast. There is no way, I could pretend to understand them all. (nor, I suspect could anyone else). This means basically you have to learn a subset as needed.
It also means that for any average developer there is a huge amount of code that will never be used, and for Microsoft a need to make all this available and downloadable in one go. (consuming link bandwidth and so on unnecessarily).

So, at this time (June 2018), we are seeing a transition to parcelling things up into manageable chunks. This is what .Net Core is all about. My advice to you would be: just keep it at the back of your mind for the time being and don’t worry about it.
VO brought about a major simplification in software development: namely it automated all the underlying electronic control, thus relieving the developer from any need to even think about it.
Beyond that, my advice to you is just forget about the way VO was implemented – (pay homage to it and its’ developers if you like, but that’s all. Seriously it was a brilliant bit of foresight).
.Net embraces that automatic control of electronics – garbage collection – something over which your programs can take control if you need to, but that’s for later.

As I said above, implementation of things is complex. It is Visual Studio that orchestrates things overall: basically, we are enabling VS to accept a simplified manual input from us as developers and translate that into full, accurate and concise control over all constituent elements.
Clearly, we have to set up Visual Studio to do this.
(Conductor/orchestra is not too far off as an analogy)

As Wolfgang said somewhere you are entering a far broader arena than ever existed with VO.

It is the setting up of VS where I think you are having problems. In the orchestra analogy we don’t want a violinist amongst the brass. In VS violins are grouped into the strings section and trumpets the brass. To get some handle on what is grouped into what:- in Solution Explorer take a look at the references and see what has been referenced automatically – you’ll soon see and get used to the groupings.
Just to encourage: I said understanding was much easier than implementing. Well you’ll come across many things which whilst terminologically different actually mean the same thing in another context. So, understanding becomes so much easier if you can build on meaning rather than implementation.

I am not qualified nor able to make any comment re XSharp or XSharp Core. Everything I say is my take on .Net in general and C#. However, since XSharp is built to address the CLR, there should be a reasonable read-across.
Others here are far better qualified and able to help with XSharp than me.

Nevertheless, I do hope this helps a bit. If this is the sort of thing you’re after I can try and summarise it diagrammatically.

Best Regards
Terry

Please Log in or Create an account to join the conversation.

Last edit: by Terry. Reason: Original advice - forget about VO was nonsense. I meant the way VO was implemented. The VO language is the essential carry-through to XSharp.

X# Core - which way? 8 months 3 weeks ago #6

  • tom@dieselworks.com.au
  • tom@dieselworks.com.au's Avatar Topic Author
  • Offline
  • Posts: 33
Thanks Terry and others for the guidance. I think I am getting it, but I can see the light is still far... but at least progressing.

Re: "VO brought about a major simplification in software development: namely it automated all the underlying electronic control, thus relieving the developer from any need to even think about it."

I like to reflect my view on this as it may help to steer things to some extent. While my history with the binary world goes back almost as far as it could in respect of my childhood, I was introduced to the Binary world in grade 7, I learned to build little calculator, would be ambitious to say computer, from AND & OR gates in the mid 70's and was programming Canon Canola SX320 if I remember correctly in the early 80's in machine language doing regression lines, so one can guess I am not afraid of these things, but I honestly think that converting business logic into code and doing system/low level programming is similar to having very good memory and being very logical, somehow most people gifted in one or the other but seldom both.

VO gave us the ability to implement complex business logic without being concerned about the underlying layers of system code. this is why some of us stayed with it for so long. I am not afraid of C#, C or even low level programming, but I am not interested, and have no time for it. What I want is implement/convert business logic into code and not to worry about all kind of intricacies of the OS, compiler and so on. I know this is likely to remain a dream, so here I am looking forward to minimise the compromise :-)

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #7

Hi Tom
I am sure the sentiments of your last paragraph accord with those of most people here.

I take the view that Software Development is about both communication and implementation.
How do we encourage (or force) the user to put the data in correctly, in the first place then how do we provide an output which leaves, ideally, no room for misinterpretation?
There is no way, in todays’ world that anyone could do it all from scratch. Instead a .Net enabled language enables us to integrate bits and pieces from all over the place.
If some bits are not quite what we want we can modify them.
For example, learning the intricacies of WPF is a major time-consuming task on its own. So we could probably find some library which does the job for us.
Of course, we could use notepad and write a program to link all this up. It would work if we did it right and hadn’t gone mad in the process.
How much easier to set up Visual Studio to link it all up for us.
We can do this if we arrange our code in a way which the compiler understands, and VS can control.
All we need is to arrange things in a standard way.
Namely group everything into the same thing – a namespace and then “nest things” further down as required.
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.
By doing this, things match the way we think as human beings – we can arrange our code to address things at a fairly shallow level over a broad range, or at detailed level over a narrow range. Not both at the same time.
Everything in .Net is a type. We start off with an assembly which is simply obtained from our solution file structure as per MS Build and project Files, then we have namespace and at first level of nesting we have a class. Nested within the class we get fields – standard OOP stuff.

Hope that hasn’t muddied the waters too much.
Terry

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #8

Hi Tom,

tom@dieselworks.com.au wrote:
VO gave us the ability to implement complex business logic without being concerned about the underlying layers of system code. this is why some of us stayed with it for so long. I am not afraid of C#, C or even low level programming, but I am not interested, and have no time for it. What I want is implement/convert business logic into code and not to worry about all kind of intricacies of the OS, compiler and so on. I know this is likely to remain a dream, so here I am looking forward to minimize the compromise :-)

I think you sum it up very well.

Knowing Pascal V4+ /Delphi there are a lot of it in what you see today in how .NET programming languages work which I believe helped me when I started with Vulcan:

The one advantage we have with using X# as development tool. All our business logic sitting in VO can with minimal effort brought into .NET.

From a front-end perspective we have to do some work if we make the decision to move to Forms/Entity Framework/WPF, but that is life.

The big advantage is that .NET is language agnostic. My X# can consume C#/VB.NET assemblies, I can subclass any other language class and make them X# and vice-versa. No DLL hell.

Well not as "fluent" as Terry's post, but I hope you understand.

Regards,
______________________
Johan Nel
George, South Africa

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #9

  • wriedmann
  • wriedmann's Avatar
  • Away
  • Posts: 1436
  • Karma: 6
Hi Tom,

I will try to add my point of view: VO gave us the possibility to work at a high level of abstraction, but also to go down to the level of a C/C++.
X# should do the same: you can work with the Core dialect - like C#, or use the VO/Vulcan dialects with all known functions, array, codeblocks, weak typing and late bound code.

The only thing that is missing currently, but will come with the time, is a GUI and data access library.

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #10

  • tom@dieselworks.com.au
  • tom@dieselworks.com.au's Avatar Topic Author
  • Offline
  • Posts: 33
Thanks All,

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?

TIA

Tom

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #11

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?

:lol: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,
______________________
Johan Nel
George, South Africa

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #12

  • wriedmann
  • wriedmann's Avatar
  • Away
  • Posts: 1436
  • Karma: 6
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.
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Last edit: by wriedmann.

X# Core - which way? 8 months 3 weeks ago #13

  • wriedmann
  • wriedmann's Avatar
  • Away
  • Posts: 1436
  • Karma: 6
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #14

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

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #15

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

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #16

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

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #17

  • tom@dieselworks.com.au
  • tom@dieselworks.com.au's Avatar Topic Author
  • Offline
  • Posts: 33
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

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #18

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. :P

Dick

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #19

  • wriedmann
  • wriedmann's Avatar
  • Away
  • Posts: 1436
  • Karma: 6
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
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

X# Core - which way? 8 months 3 weeks ago #20

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...

Please Log in or Create an account to join the conversation.

  • Page:
  • 1
  • 2