We have a .NET 4.x project and a Qt 5.x project.
We would like to use one or more QWidgets from the Qt project in the .NET project. The widgets would ideally be added to a forms control if possible.
What is the recommended way to solve this issue? One option is to use ActiveX.
I've spent some time working on an application that mixed Win32, WPF, and several flavours of Qt, and you can get it to work although it may make a few of your hairs grey
You can host native controls in a WPF application: https://msdn.microsoft.com/library/aa970061(v=vs.100).aspx
Qt can be hosted in native Windows apps using the qtwinmigrate project https://github.com/qtproject/qt-solutions/tree/master/qtwinmigrate. Note - I've only used this to host dialogs, not embed individual controls, so I don't know thats actually a possibility. I've also had an extremely difficult time getting the messages pipes from all 3 systems to play nicely together, but it is (more or less) possible I think.
The real question is if you have WPF at your disposal, is it really worth getting the Qt in there? You would need to have a fairly large existing widget to justify the pain.
Related
First, some background:
I've decided to start a new project designed from the ground up to run on multiple platforms (Windows, iOS, OSX, Linux, Android). Since my background is mostly C++ I intend to write the core functionality using C++11. That being said, on each platform I'll need to write a platform-specific UI that can inter-operate with the C++ core.
The first platform I'm targeting is Windows (the second is iOS). I will have data stored in a SQLite database as well as user-supplied data that will be entered using a WPF DataGrid (inserting rows, manipulating existing data, etc.). This is my first time working with WPF (though I've used Windows Forms) and my first time working with C++ in a managed environment. I plan to make this an MVC-style architecture so in my mind SQLite is the Model, WPF is the View, and the C++ code is the Controller.
My question is this:
Are there any examples out there illustrating how to grab data from a C++ interface and display it using C# and WPF without destroying/mangling the C++ code itself (since it must work on multiple platforms)? I've read a tiny bit about P/Invoke (tedious, but works) and mixed assemblies (works, but will mangle my C++?) but Google hasn't been helpful when it comes to concrete examples (especially those involving populating WPF controls with data obtained via a C++ DLL).
Thanks!
EDIT: While searching for approaches to this problem I came across CXXI. I'm not very familiar with it but it seems like it may be a simple solution to my problem. Any thoughts? My grasp of all these concepts is limited.
Having worked with both XAML and WinForms, I don't think you'll find WPF to be feel much more "native" than your WinForms experience. In both cases, everything is abstracted by .Net. But if you want to learn WPF, then go for it.
P\invoke works just fine as does COM. As for other ways of getting data from C++ to other languages, consider approaching this as an IPC problem rather than a language one. Run one process as the child of the other and look at sockets and libraries such as 0mq/clrzmq (see this for 0mq on iPhone--this for Android) and Thrift to get C++ talking to the other process.
With sockets/0mq, you can use xml/json/Protobuf/Protobuf-net to serialize and deserialize objects from one language to the other. With Protobuf, you'll only need to create one set of json-esque data objects and use the langauge-specific tools for generating code. That'll take care of your data objects across platforms and languages, allowing you focus on the fun stuff. Serialization will work nicely with sql, too. All of these technologies are easy to implement and each has a score of language implementations, making it simple to wire things up to your next GUI.
In regards to examples, it all depends on how you want to move your data between the runtimes.
I'm pretty excitet about all the new stuff coming up in Windows 8, but at the same time a bit worried about how and if I can continue use the code and custom components I have already built up using .NET and C# during my time as a Windows dev. I've got some general mixed questions about this. Hope you don't mind I'm putting them together in one post:
Will Windows 8 Store be for both metro-style apps and regular WPF-desktop apps? Including pushing updates and making apps available for company employees?
Will the new App Contract-thingy also be available for WPF-apps? And is AppContract based on WCF-services with perhaps UDP-discovery on the network? Can I make my own contracts between my own apps using the App Contract framework?
I'm not particularly worried about if WPF will be ditched or not. I can live without it. The thing that worries me is if I still can write presentation and business-layer code in C# and use it as a backend for my apps, no matter what UI-framework I'll be using, HTML, Silverlight, WPF or what have you. If I'm still able to write logic in C# and present it using X UI-framework, I'm a happy developer. I've heard I can access the .NET-framework from JavaScript. But what about custom assemblies?
It has been announced that non-Metro apps can appear in the store but the store will just link to the publisher's website - not actually manage the sale/install/DRM/etc stuff.
What's been announced so far is that the contracts are only for Metro apps but I'd be shocked if this doesn't change. It would be crazy for Microsoft not to allow desktop apps to, for example, add commands to the Settings charm, support PlayTo or printing through the Devices charm, or act as Share sources. We'll have to wait and see where they draw the line on what desktop apps can/can't do.
Sharing code between Metro and non-Metro apps is going to be very difficult. A lot of the core concepts and conventions are the same but even basic stuff like file I/O rely on a totally new API. There aren't a ton of interesting things you can do with in code that will work on both sides of the fence. Best bet would be to define interfaces for your business layer stuff and then use dependecy injection to dynamically select desktop vs. winrt implementations at runtime
Store: there is no final information but as far as I understood it, it's for metro style applications only
The app contracts are a metro thing. I know a code snippet that documents usage from desktop apps (eg http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), but I do not know if it will have support from Microsoft
WinRT compiles libraries to WinRT components. You might be able to reuse code and compile them to a component as long as you're not using a namespace that isn't available for WinRT
This question is heavy on guessing as there is no official beta available. And even then we can't be absolutely sure...
I’d like to develop an application with a complex GUI (combobox with animation, charts with spline, transparent layers, …). I have good experience with C# 2.0 and I’m studying WPF, but I read that, unfortunately, there is no plan to port WPF to Mono.
If I stick with C# and create custom GUI controls using OpenGL (via OpenTK), I feel it will be a hard work (integration with GTK#, debugging, hard to use to design forms).
I can use Java (with JOGL), but I’m not very skilled with it, and I don’t know about performance issues.
Last option is C++, but I have to do a big revision (years since last time I used it), and I find it hard to develop GUI and portable applications in C++. (Maybe I’m wrong! Still, I’m quite afraid to develop such complex application with this language.)
What is your advice? Had I better choose C# + OpenTK, Java + JOGL, or return to C++?
I would go with Qt. Take a look at http://qt.nokia.com/products/ . If you are afraid of C++ (but there is no reason to be afraid of it), you can try with Java Swing. I think that those are the best options to go with multi platform desktop GUI development.
I would suggest Mono and GTK#. Developing apps with .Net is far more effective than doing it in C++ vanilla. Sure, you have to stick with C# 3.0 and .Net 2.0 (some features from 3.5 is implemented, like LINQ). But it still gives you a lot more than C++ with, for instance QT, would give you.
Go C# for productivity. Nothing against C++ but it's a bit verbose.
As for the GUI library, I think WinForms used to work on Mono. Alternatively, GTK#.
I would not suggest using wpf for it is a platform dependant platform. Silverlight might be a better option.
But if you are developing a web application, jquery would be a nice option you also might consider adobe flex and adobe air; http://www.adobe.com/products/air/
Does multi-platform have to include iDevices? Can it be on the web? Those are 2 questions you have to answer first.
If you can live without iPad/iPhone suppport, then Flex/Flash/Air is good option for highly graphical things. It is multi-platform for sure and easily integrates to the web. Probably your best option for this case with the limited details given.
Qt could work for you as well, although I can't say for sure if it's graphic library will make it easy. I've personally never worked with it, so other would have to answer that. But since it is in C++, you could use other libraries as well.
Java Swing sounds rough to me for this complex of a GUI. Making some basic stuff isn't too bad, but if you are expecting an experience like with C# I think you will be frustrated. Just a personal opinion of course.
Lastly, if it can be a web app, why not stick with C# and Silverlight? A .NET solution may work well for you since you are already learning it.
Silverlight runs on Windows/Mac/Linux and some handhelds, and is being ported to more handhelds. I believe Silverlight will ultimately be ported to every popular device.
Silverlight is:
Much, much more powerful than Flex/Flash/Air.
Much, much more powerful than Qt.
Ridiculously more powerful than GTK+ or GTK#.
Ridiculously more powerful than JOGL.
Silverlight has all of the features you have requested.
Silverlight works very well with C#, which is a much more productive language to work in than C++.
Silverlight is basically a very large subset of WPF, so if you already know WPF, you already know Silverlight.
Unless you absolutely require iPhone/iPad support I think the decision is perfectly obvious.
See this comparison of WPF and Cocoa to get some feeling of how WPF/Silverlight compares with the likes of Qt, Flash/Flex/Air, and GTK#, all of which use a primitive WinForms-like object model similar to the one used by Cocoa.
At my day job (a well-known microprocessor company) we develop complex engineering apps with Java, Eclipse RCP, and Java OpenGL. Performance is good -- we can easily get many millions of polygons/second and up to 100 frames/second. The SWT widgets in Eclipse are fast enough where we haven't had to render any custom controls with JOGL.
I've got a set of tutorials that shows how to get started with this kind of programming. The series starts with http://wadeawalker.wordpress.com/2010/10/09/tutorial-a-cross-platform-workbench-program-using-java-opengl-and-eclipse/.
First, don’t use C# for anything that should be portable. Mono is a bad option for GUI for two reasons:
Mono goes always several steps behind .NET.
Mono does not support WPF, so the only way to develop GUI is using something like GTK#.
My personal opinion – use C++. It would give you very good portability and independence.
You have two options:
Qt4 – very good GUI toolkit, makes GUI development very easy, and highly portable.
GTKmm – also very good toolkit, but it feels less natural on Windows.
Also, Java has Swing toolkit that comes with JDK and is available on all Java platforms, even very strange ones like OpenVMS.
I've been playing around with C# console applications for about a year and I want to move on to creating GUI applications. I have never done any GUI development besides basic Java applications, but I want to continue using C#. Should I start learning Windows Forms or jump straight to WPF? Is there a huge difference? Does WPF build on top of Windows Forms or are they totally different?
If you're just starting out, jump straight into WPF.
It will allow you to get starting making rich interfaces using mark-up to define your interface without teaching you the possible bad habits (for WPF) that you'd learn from Windows Forms.
These two are totally different technologies. They do offer some interoperability layers to both directions, but other than that have nothing in common. Windows Forms is more or less a lightweight wrapper on top of Win32/MFC, which means its extensibility in .NET is not that good in all cases. WPF is a new UI framework implemented from scratch. WPF is also much more flexible when it comes to customizing the existing types.
However, at least from my experience, Windows Forms seems to be the more commonly-used desktop UI framework in the industry. Windows Forms can't be used with web development though while WPF offers Silverlight and XBAP applications.
If you have done any UI development before, I'd dare say Windows Forms is easier to learn as it follows more traditional programming paradigms. The programming model of WPF is quite different to this. While WPF can be used in the same way as Windows Forms, most of its benefits are not achieved until you embrace the data binding and encapsulation WPF provides.
Despite stating some points in favor of Windows Forms choosing WPF over Windows Forms would be a no-brainer for me if all you want to do is learn a UI framework. It's superior to Windows Forms in all aspects. I just wish the software industry in general would adapt it on a larger scale! (Though not like anyone writes desktop applications any more since we got the web.)
Both technologies have their pro's and con's.
WPF is better for cross platform development and creating 'flashy' GUI's. However it requires a newer .net framework than WinForms and requires a dx9 compatible GPU or higher (which most people will have).
But it is a little bit more involved to create the interface / wire up all the events etc.
WinForms is still a powerful technology which can often be developed at a faster pace than WPF however, in the end, both technologies can be used to achieve the same thing. However WPF is the 'newer' standard.
WinForms is commonly used to develop business applications whereas WPF is often used to create more end-user based bits of software, apps etc.
WPF provides very rich facilities to build extremely complex user interfaces. It simplifies integration of a hardware-accelerated graphics in your interface. However, the Visual Studio WPF designer is really bad (I almost never use it). I also think that WPF is much more complex, and it is more difficult to start with. But this is subjective of course.
I have an app that I've written in C#/WinForms (my little app). To make it cross-platform, I'm thinking of redoing it in Adobe AIR. Are there any arguments in favor of WinForms as a cross-platform app? Is there a cross-platform future for Winforms (e.g., Mono, etc.)? Suggestions for cross-platform UI development?
By cross-platform I mean, currently, Mac OSX, Windows and Linux.
This question was asked again and answered with better success.
As far as my experience in Flex/AIR/Flash actionscripting goes, Adobe AIR development environment and coding/debugging toolsets are far inferior to the Visual Studio and .NET SDK as of the moment. The UI toolsets are superior though.
But as you already have a working C# code, porting it to ActionScript might requires a redesign due to ActionScript having a different way of thinking/programming, they use different primitive data types, for example, they use just a Number instead of int float double etc. and the debugging tools are quiet lacking compared to VS IMO.
And I heard that Mono's GtkSharp is quiet a decent platform.
But if you don't mind the coding/debugging tooling problems, then AIR is a great platform. I like how Adobe integrates the Flash experience into it e.g. you can start an installation of AIR application via a button click in a flash movieclip, that kind of integration.
I'm thinking of redoing it in Adobe AIR
Not having spent much time with AIR, my personal opinion is that it is best for bringing a webapp to the desktop and provide a shell to it or run your existing flash/flex project on the desktop.
Btw, if you don't know ActionScript, I mean its details, quirks, etc, don't forget to factor in the time it will take googling for answers.
Are there any arguments in favor of WinForms as a cross-platform app?
Is there a cross-platform future for Winforms (e.g., Mono, etc.)?
It's always hard to predict what will happen, but there is at least one project (Plastic SCM) I know of which uses Mono Winforms on Win, Mac and Linux, so it is certainly doable. However, they say they built most of their controls from the ground up (and claim they want to release them as open source, but not sure if or when), so you will need to put in some work to make things look "pretty".
I played with Winforms on non-windows platforms and unfortunately, it isn't exactly "mature" (especially on Mac). So what you get out of the box may or may not be sufficient for your needs.
If you decide a desktop app is not the best way to provide a cross-platform solution, you can always take your business logic written in C# and create either a full-blown webapp with ASP.NET or go with Silverlight, so many other options exist with C#.
WinForms are fully supported by Mono, so they are cross-platform.
Why would you go with Air?
Use GTK#, and you have a cross platform forms engine and you get to keep your C# code.
Well I think the only way to for cross-platform reliably with C# is Microsoft Silverlight, but is not really WinForms, and browser-based. Other than that, yes Mono is a chance.
If you want to use the .net Framework, Microsoft Silverlight is a good (the only?) choice. The browser does a good job as a shell, but you could also write your own application shell for it. For example, Scott Handelman mentions the NY Times Reader written in Silverlight and hostet on Cocoa on a Mac.
I don't think there is a future for WinForms at all. Since it appears to have been a stop-gap solution even in MSFT world ( a very thin wrapper around Win32). And virtually no changes seem to have been made to System.Windows.Forms in both .NET 3.0 and 3.5
</speculation>
I would use Java or Air.
I think that as long as you make sure that the business logic code you write is cross-platform (i.e. using backslashes in paths only works on Windows - forward slashes works on all OS's), then Mono shouldn't have major problems running an unmodified WinForms program. Just make sure you test for graphical glitches.
I asked a similar question last week. I've been using Mono all along, and have had no issues running the applications I compile to IL to run on SuSE linux (I usually run KDE) or windows, however, I've not gone out and got a mac yet to test it on. I will be soon, though, probably with in a couple weeks. But all and all development in Mono has been very good at creating application that will run on multiple platforms.