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.
Related
I had create a WPF application and i am doing a documentation about it. Inside my documentation, i need to state down the hardware and software requirement for my WPF application. Is that anyway i can check the requirements for the WPF application? Thanks.
About my application:
Target Framework: .NET Framework 4 client profile
Output type : Windows Application
I am not sure I understand your question 100% but I will try anyway to help you.
When developing with WPF, among other things, the graphics hardware is a very important element.
The level of graphics hardware capability and performance for a device that runs a WPF application is defined by rendering tiers. The MSDN link describes the types of tiers and the minimum graphics hardware.
In short you can get the render tier for the current thread using RenderCapability.Tier.
In code
int renderingTier = (RenderCapability.Tier >> 16);
If you make use of some heavy graphics effects in your WPF application, then it is probably suggested to run it on a system with RenderCapability.Tier > 0.
I want to build a rather complicated GUI app on the .Net framework. The app will have the following graphical capabilities:
Plotting/updating realtime data
Allow manual (using mouse) drawing/dragging/editing of lines etc on a plot
Allow selecting of graphical objects/shapes on a plot and drag/drirop to a new location on the plot
Ideally, I would like to use VS to do my initial development, because the VSIDE is (understandably) much more sophisticated than the monodevelop tools. However, I will be running the application and maintaining the codebase (once the development phase is completed), on Linux, using monodevelop.
It is important for this reason, that I make sure that I do not use any .Net components that have not yet been ported over to mono.
Given the graphical functional requirements above, I would like to know if I can expect to be able to develop such an app on Windows and then port to monodevelop?.
I am aware that components like WPF have not been ported to mono, so are there any other .Net GUI components (available on mono) that I can use in my application (to make the port possible)?
From a past experience start with a Windows Forms plain app. If you want the port to be as clean as possible forget about complex UI components, you can always use your custom controls but check third-party ones you use don't call Win32 API directly. That you can do it within Visual Studio (check this plugin for more productivity) but I want to warn you about two things:
Interfaces built with Visual Studio (WinForms) when running on Linux look awful.
If you want a clean UI take a look at Gtk#
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.
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
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.