Metro and web apps have an analogy : page-based UI…
Another question is where is Windows going. MS seems intent of pushing Metro to the detriment of the older, window-based interface. It impacts the future market.
Verb
To make malicious, underhand remarks or attacks. ?
Unnecessary, uncalled for & adds nothing to the conversation
See https://forum.xojo.com/4307-forum-etiquette-and-notices
[quote=54959:@James Dooley]As a 20 year plus veteran of windows programming , I must say I find this discussion interesting, but also dated and with several misconceptions!
First of all XAML does not use DirectX, in fact DirectX never really made it!
WPF, WCF, Silverlight etc never really took off - yes most companies have a few apps running on this technology, but most apps are still Winforms, ASP.NET and standard web services.
.Net does not use OleDb for data access. In most cases it used providers built on top of native libs
While .Net does produce 64 bit apps, many business apps are still 32 bit, because many of the interfaces they use are still 32 bit - the Oracle driver is one example that comes to mind!
At this stage .Net is starting to reach end of life and I really would not want to see this vendor investing heavily in it right now. Better to wait and see where MS decide to go.[/quote]
James,
Sorry man, I find these remarks to be 100% wrong. In fact, none of it makes sense.
- WPF is considered THE desktop object model and the “chosen” model to use when creating a desktop Windows applications. WCF, Silverlight and WinForms are NOT part of that discussion – Those things are being phased out. But if you’re creating a C# application that runs on the Windows desktop, you will most certainly use WPF and XAML – which renders its objects on the screen using Direct3d (i.e. DirectX) – see the below link for an explanation. But Xojo needs to “wrap” that namespace and provide native access to that new framework to replace the existing Win32 – which is also being slowly phased out.
http://msdn.microsoft.com/en-us/library/aa663364.aspx
- .NET most certainly DOES have OleDb for data access. Its through System.Data.OleDb, and it uses the underlying OLEDb model to access databases. .NET has many means to access data sources – LINQ comes to mind, and yes, the “native” System.Data.SQLClient; namespace – but please do NOT say that .NET “does not use” – .NET is merely a name of a technology that describes a programming model and development platform that MS is supporting. It most certainly allows for many different ways to access data.
http://msdn.microsoft.com/en-us/library/system.data.oledb(v=vs.110).aspx
Lastly, .NET is NOT hitting an end of life. It’s at 4.5, and they are adding more and more technologies to that food chain.
Its frustrating when I read things like this.
Just becasue Microsoft says so does not make it so!
Given the large number of vendors still producing and supporting WinForms controls and job advertisements seeking WinForms experience, should give you some hind that all is not well in the land of WPF. The fact that WPF is not THE way, but a way of creating Win8 style apps is another indication that there is issue with it… Large scale WPF applications are complex to build and maintain, which is one of the reason that the up take has not been so great.
OleDb is available on .Net, just as ODBC is, but they are both there for backward compatibility! The providers used to access MS SQL Server, Oracle etc… to not rely on OleDb for connectivity, they interface with the CLI in most cases, although Oracle does now have a managed provider as well.
.Net is becoming legacy, just as Java is… We have pushed them as far as they can go and to get to the next level and provide performance levels required requires a new approach, one of the more promising technologies in this area right now is Node.JS and not surprisingly MS is starting to support it with development tools, IIS support and Azure capabilities. The underlying language in Node.JS is Javascript, which is also that championed by MS for developing Win8 apps… and with good reason, Javascript has one very important feature, unlike our other toolsets, it can be used to write non blocking code!
To build top flight apps for Win8 or highly responsive web sites, requires a paradigm shift and will not be achieved by simply bolting on .Net and Twitter Deck to XOJO! In this respect XOJO and .Net can still be used to do middle tier and back end work, but what tools will come along to give is the productivity boost we need to build great front ends remains to be seen…
In the short run, I think the quickest ‘win’ for XOJO would be to open up the WebKit more so that developers could develop mesh up style apps, taking taking advantage of some of the frameworks already available on the Javascript side, while still benefitting from what XOJO has to offer.
Not sure what you mean by “open up the WebKit”
Whatever front end framework you want to use has to somehow integrate with the code that is your app - which is all running on the back end server side.
That said you can create web custom controls that wrap up other controls from other frameworks etc o you can use them in Xojo
There’s a few examples in the WebSDK directory next to your install of Xojo - YUI Rich Text Editor, jQuery Calendar & a few others.
I understood the suggestion to mean using WebKit in desktop applications, not web.
[quote=55196:@Norman Palardy]Not sure what you mean by “open up the WebKit”
Whatever front end framework you want to use has to somehow integrate with the code that is your app - which is all running on the back end server side.
That said you can create web custom controls that wrap up other controls from other frameworks etc o you can use them in Xojo
There’s a few examples in the WebSDK directory next to your install of Xojo - YUI Rich Text Editor, jQuery Calendar & a few others.[/quote]
It sounds like he meant to use WebKit for the desktop GUI. While an interesting prospect sure, it means controls would not be native. That would put Xojo on par with most other cross platform toolkits, which isn’t a good thing.
I agree that WPF adoption never took off. In some isolated cases its awesome but generally speaking most places don’t use it.
Don’t confuse WPF with Metro or Silverlight. WPF is the logical progression from Win32 on the desktop.
It’s certainly NOT dead.
http://blog.arsanth.com/index.php/2011/09/15/what-is-and-isnt-dead-in-windows-8/
I don’t confuse it. I use Xojo as much as .NET. I have many clients and been using WPF since before it was called WPF. I don’t think WPF adoption is even 20% of WinForms.
WinForms is being EOL’d… WPF is replacing it. That’s why the adoption is smaller.
WPF will be the framework moving forward. WinForms is effectively not being developed.
WPF came out years ago - its not like its some new thing that Microsoft intends to replace WinForms with. Windows 8 apps don’t use “WPF” although WinRT does use XAML if you use managed code. I don’t think any of the desktop-era tools like WinForms/WPF are considered the “future” at Microsoft.
Let’s forget the “future” of Microsoft. Let’s remember, we’re talking about Xojo and desktop Windows native applications.
We need replacement for the Win32 code base – and thats WPF.
Two reasons for that. WPF supports visual aspects like 3d and animations by using the Direct3D and DirectX for its rendering of screen objects. There’s an abundance of newer components and the use of XAML helps with the MVVM paradigm – something that Xojo would be smart to utilize.
So IMHO, the right path for Xojo is WPF / XAML, not WinForms. WPF applications will run brilliantly on Windows 8 – you aren’t going to be doing that Metro stuff, but thats the point – this is for “classic” desktop development.
I hope that I am not misreading. Is Xojo for Windows going to be another .NET language?
Then I have to revisit the question I have been asking myself - Xojo or Visual Basic 2013? Only this time, it is no longer native vs intermediate but which .NET language. Which then the answer is Visual Basic will always be up to date and it will be there waiting (with open arms) when new features are announced by MS - eg. Windows 8 Apps, x64, etc etc. No need to wait, no need to push for features updates, and it is (always?) free.
What we do need is an updated framework for Windows that can give us something like fully double buffered window compositing like OS X has. That would be really nice. No more flicker. And access to the many other controls & frameworks available on Windows with a lot less pain.
But at this point don’t get to stressed about “OMG their going to just be another CLR language” as that has NOT been decided.
We do need to update our Windows support and we have discussed .Net & whats possible but that’s about as far as its progressed.
I apologize if the terminology of “a .Net framework” has caused anyone angst & grief.
Hi Norman,
Thanks very much for the clarification. I feel relieved for now.
Maybe I should have said, “Xojo needs what WPF is using as internals” – not WPF or .NET.
The confusion here is thinking that Xojo will just leverage the concepts of WPF. Its more that Xojo needs to replace what Win32 is and utilize some of the things in WPF that its using to render objects to the screen from Windows.
One thing that I haven’t looked into is that if WinForms simply wraps the Win32 SDK. I seem to think that it does. And if thats the case, thats another reason why the underpinnings of WPF are more desired.
Yeah, its all very confusing – but can we get iOS support first?
LOL
iOS is coming along nicely actually.
I know there hasn’t been any public posts about it in a while - but it really is.
http://www.xojo.com/blog/en/2013/09/progress-report-on-ios-support-in-xojo.php
and there are sessions on it at XDC see the sessions for Joe Strout https://xojo.com/xdc/sessions.php
Yeah ! Great ! 
He said iOS is coming along nicely, not Xojo’s support for iOS. 
<–note the winky, please. LOL