I have a WPF application which runs on a Windows 10 IOT device. The device has 4 inputs and 4 outputs and they should be read and written from a new release of the application.
All the sample code about GPIO I found are based on using Windows.Devices.Gpio;.
I made some tests with Visual Studio and I need a reference to Universal Windows which is available only if I create a new project for UWP. It seems I cannot add GPIO functionality to an existing WPF project. What can I do? I would like to avoid porting the WPF project to UWP. A workaround valid only for the specific platform (x64) is acceptable.
Update 1
I added the references reported in the page suggested by Elgar and now I can compile using classes from Windows.Devices.Gpio namespace. Cannot access target hardware till next week so I cannot say if it works, but it is promising. In fact my development workstation doesn't have Gpio so I think it is correct if GpioController.GetDefault() returns null.
I found a NuGet Gpio package too. It refers to a completely different namespace, System.Device.Gpio, some classes look like the ones in Windows.Devices.Gpio but there are differences in the methods. I'm a bit disoriented because I cannot find any documentation on this package.
WPF on GPIO? It is not possible.
GPIO on UWP is an abstract layer that communicate on IOT's graphic subsystem devices, whereas WPF is on top of DirectX 9.0c. Those two are completely different in architecture and on the fundamental hardware abstraction layer. Therefore you can't mix UWP that runs on top of GPIO with WPF that runs on DirectX.
I've been developing a windows store application for a windows 8 tablet (Microsoft surface). So far the application has been designed using XAML-RT/C# using a SQLite database. The application won't be released via the store, it'll be just used internally by my company.
I am however finding numerous problems with the platform. i.e. speed of the surface device, releasing versions and renewing the developer licences.
As the application is still in the development stage and no decision has been made on the final tablet I'm thinking about re-writing the application using WPF and using a full windows 8 tablet (not a RT/ARM version). This way I can use full SQL and have much more control over releasing the software.
So, my question is...
What is generally the best development platform for a full windows 8 tablet? Is it best to go with WPF or stick with the Xaml for RT?
Thanks
WPF
less sandbox limitations (can call any APIs)
is currently somewhat easier to do enterprise deployment with
has more features
is more mature overall
can benefit from Surface SDK 2.0 controls for great touch support on big screens
WinRT/XAML
works on ARM devices
is lighter and faster
has built-in modern touch-enabled controls targeted for tablet use
might be better suited for use on tablets overall
Overall the main benefit of WinRT is that you can use it on ARM tablets which are cheaper, lighter and more usable as tablets. WPF requires heavier devices and might be slower, but you gain the ability to access all legacy APIs.
If you intend it to be fully touch screen ready then you'll have to do some extra work in WPF to get the level of UI interactivity that you get from the "metro" apps.
That being said, if you're writing a complex application that requires lots of API calls/web services and file handling then you're going to have a much easier time with WPF.
I need to create a desktop application for Windows and I'm in doubt about which technology to choose. Fact is that the application must do interaction with local resources:
Communication with SQL (need support for SQLite and MSSQL - local and remote, and would love to use NHibernate; maybe even with Castle's ActiveRecord)
Interaction with equipment connected via Bluetooth, Ethernet, USB and Serial (COM) port. I need to read a byte stream from sensors that connect via different protocols.
Preferably I'd go for Silverlight 4, and allow the application to run on the desktop with Full Trust. But I foresee problems with regards to these two requirements. Is there any solution for SL4, and if not, what alternative should I choose? I'm not limited to WPF or WinForms, but since it should run on .NET, I'm more or less limited to these 3 options (or am I?)
With a Silverlight app, you won't be able to connect to a SQL source without creating a service + you won't easily (or at all?) have access to the local resources such as COM port. If your app is intranet based, I'd go for WPF and click once deployment.
After you understand how to use WPF/Sliverlight controls, templates and data binding you will never want to touch WinForms again - it's not only that WPF/SL gives you a richer UI possibilities they just make it easier and less error prone to create applications (especially data-binding).
And it looks like you need relatively low level hardware access, even if it's possible with SL it will be easier with full .net
So, I would choose WPF
Just remember WPF/SL have a learning curve, if you never built a WPF project budget some time to learn the platform.
WPF would be your weapon of choice.
API-wise, WPF basically is a superset of Silverlight. Moreover you are in full control and have complete access to local resources.
If you are into .NET 4.0, you would probably enjoy Entity Framework, as an alternative to NHibernate. Not that it exceeds NHibernate in any way, but it integrates beautifully and comes with the package.
But, as Nir also stated, there's a learning curve for WPF.
Silverlight 3.0 beta has just been announced at Microsofts Mix Conference in Las Vegas.
Two features of the new beta are 3D-graphics and the ability to run applications outside of the browser, which to me seemed to be two of the major features that WPF (Windows Presentation Foundation) previously offered over silverlight.
I am currently evaluating WPF and Silverlight for possible use in our companies future development activity, and this announcement has left me confused as to the intended direction of these two UI technologies and why I would choose one over the other.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision? Given the announced changes to silverlight, Would your decision have changed had you made it now, and if not, why?
Any advice would be appreciated.
The biggest difference I find is the asynchronous model you have to adopt
in your Silverlight application.
It does seems like an advantage (and it can be), but it does make
life very difficult sometimes.
There are also some limitations that can be a real challenge like the absence
of print support.
I would recommend Silverlight over WPF when:
- There is no need for best possible performance (graphics included)
- Can get around the absence of print support (it will come, we just don't know when)
- Camera/Microphone support is not needed
- Can tolerate the assync app/development model
- Can tolerate limitations on WCF (no support for WS-Security at this point)
- There is no need to store huge amount of data on the client.
- There is no need to direct integration with client side applications like Office.
- Has a server to host your application
I would say the main difference is that WPF requires the client to have the .Net 3.0+ framework. Silverlight only requires the runtime. Now that being said, WPF is geared more for controlled environments such as an intranet. Silverlight is meant for the public web. Another difference is that Silverlight is cross platform (Windows, Mac, Linux in the future & Cross browser). WPF is meant for Windows only.
The .Net framework can be a huge download for some users. Silverlight is only 4-5MBs. This is a big difference to run your app on the web, but not a big issue if its an internal application at your company.
Silverlight is Sandboxed which is meant for web use. So if your app requires more permissions you will need WPF.
There are also some differences between Silverlight code and WPF. But from what I've heard, the ultimate goal is to get a Silverlight to run inside of WPF with minimal code changes. But they aren't there just yet.
I have just worked on a WPF project that in hindsight we feel we might have chosen SilverLight for. It is probably more important to know the differences and select the one that is most appropriate for what you're doing.
Here's my starter for ten on some of the important differences - there were originally some differences in the available controls, but that has largely been smoothed out now.
Silverlight
Runs entirely on the client with AJAX
calls to the server for data
Can run on any server, including Windows and Linux / Apache
Uses COMPACT .NET framework
WPF
Runs on the client... usually calls services for data
Runs on Windows XP / Vista with .NET 3.5
Utilises the entire .NET framework
Silverlight is basically a stripped down version of WPF in order to make the runtime libary download as small as possible.
As a result, WPF simply has a lot more functionality available in it and tasks that are simple in WPF often become not so simple in Silverlight.
If running as a web app is not a requirement then the decision is a no-brainer - WPF all the way.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision: Well since WPF was desktop only (or browser based using XBAPS - but that was more a deployment system than a real system) that was a good reason to it.
"Would your decision have changed had you made it now, and if not, why?" - No Silverlight, even on the desktop in v3, is still highly sandboxed and so certain functions are going to be hard/impossible to do due to the sandbox. Also the ability to use DirectX parts in WPF will still give another optimisation area which Silverlight and it's 3d won't be able to use.
It's worth noting that Silverlight's 3D is not the full 3D support of WPF, but only projection of 2D into 3D - i.e. take the 2D plane and allow rotation in X, Y & Z directions. WPF has full 3D modelling with materials, view ports, lighting and camera positional support etc.
I'm well along in the development of our first WPF app for release. Silverlight 3 looks great, but for this application I would still have chosen WPF. The application centers around presenting and manipulating very large sets of images hosted on a central server on our clients' networks. Additionally, the software update/change rate will be minimal. Mass import of new images from a local drive, no Internet connectivity requirements, performance concerns, etc. make this a project well suited for WPF.
One of our upcoming projects, however, will require many remote users to access a single data store on our network. The data they work with requires significant validation and error handling, so running that code locally is ideal. They will need the ability to work both on and offline and remain in synch (probably with SQL Data Services). SLOOB (Silverlight Out Of the Browser) will most likely be our choice for that one so they can have all the Silverlight advantages but use it like a regularly installed application, even without an Internet connection.
Both formats have their place: the trick will be to avoid using Silverlight for everything - we have more tools than just 1 hammer. :-)
Another difference is that with SL you only have one 'window', you can't have dialogs (they can be simulated but their size is limited to the main window) and you can't add multi monitor support.
If you have to interact with existing business applications (e.g. open a document in the archive viewer) you need to use WPF.
I recently have built several internal tool using wpf, and I chose it simply because It was easier for me coming from win32 work. I don't really think that the differences are major, and really... everything i have seen/heard indicates that porting between wpf and silverlight is quite easy.
Storage: You only have 25MB of isolated storage out-of-browser. If I remember correctly from some mix09 video, this limit is lower if your app is in-browser.
http://bliny.net/blog/post/Out-of-Browser-with-Silverlight-3.aspx
No FlowDocument: So there are limitations there too.
This may seem like a high-level question. But that is because I'm unfamiliar with cutting edge ASP.net and even less with this behemoth called Sharepoint. So please bear with me..
First off is it possible to take functional custom WPF controls which contain certain unmanaged subcomponents that do DirectX rendering (for performance reasons) and drop it into ASP.Net? as an example consider a specialized chart control
Does Sharepoint add anything that makes this possible ?
The use-case is to take certain panes or areas from a thick WPF client and slot it into an existing Sharepoint based solution.
Is this possible or are they (WPF Controls and Web Controls) as different as chalk and cheese? (Assume that the current control interface can be freely changed.) Would it wise to develop web-aware stripped down version of these controls than to attempt to hammer the current controls in somehow...
On a fundamental level, can a web-page contain a control which takes over the rendering for its client-area/rectange ? Or does everything have to broken down into plain html by the time it hits the browser.
I found a few unanswered queries online. But other than that its unexplored (or forbidden).. in either case I'd like to know. Thanks for reading..
The short answer is: Yes it's possible but you probably don't want to do it.
Asp.Net, with the exception of java script, is primarily a server side technology. Meaning that the majority of the processing code runs on the server vs. the client. IIRC share point is built on top of Asp.Net and thus has the same format.
WPF is a client side technology. The code runs on the actual physical client computer.
Combining these two technologies into one application does not work due to their conflicting natures. However, there are several options for you.
Silverlight: It's easiest to think of this as flash for .Net. It allows for rich WPF applications to be run via a web browser on client machines. It's a subset of the full .Net framework but rich enough to build great applications.Silverlight is limited in that it must be a 100% managed solution. You're post mentions using a DirectX control which I presume is native code. If this is the case Silverlight will not work for you
ActiveX controls: These allow for essentially any form of client code to be hosted in a web browser and run on the client machine. This includes .Net, WPF, C++, etc ... If you have a native component this is really your only option.Unfortunately though, ActiveX controls are following out of favor. Primarily due to their insecure nature. Once you run an ActiveX control on your machine you're at the mercy of the control author and it's easy to do malicious acts.More data on ActiveX controls: http://en.wikipedia.org/wiki/ActiveX