I am used to WPF Development. But recently, i am assigned to Windows Forms projects. Fortunately, application framework supports pluggable architecture and that's why i feel i can develop plugin in WPF.
If we safely assume that framework doesn't need more than a interface to detect a plugin, I have following questions:
First of all, is it a good idea to develop WPF plugin for the given scenario?
Are there any guidelines available which i should follow? Any Examples?
Will it be a good idea to design some abstraction layer specially for WPF plugins rather than depending on interface?
Thanks in advance.
Yeah, we have huge project called "Plugins" which is basically WPF App/Windows loaded via additional app domain.
I think in your case depends if you Windows Forms are in .NET 2 or .NET3.5. If it is .NET 3.5 then you dont need additional app domain to load .NET 3.5 with WPF.
If you are already in .NET 3.5 with your WinForms, then you can use ElementHost to host your WPF inside WinForms.
Apart from few glitches (like not repainting the form sometimes), it went quite smoothly in our case
As to your Qs:
Usually it is better to do everything in WPF, but do u have a choice ? (I dont think so)
Lookup an example on WPF ElementHost
Well, I would use MVVM with WPF so that later on you can chnage the UI bit (maybe Silverlight or Win8 metro) without chnaging much of the business layer logic
Related
I am going to start a new (Right-To-Left) WPF project and the Main reason is to provide a single UI for the application in Windows and Web.
What Should I consider?
Which WPF Controls should/shouln't (can/can't) I use?
Do I Have to Use Silverlight? (I'm not interest)
Should I use XBAP project orWindows Project with Page base modules?
TIA
Your choices are indeed XBAP (WPF Browser App) and SilverLight.
You can easily google to find lots of comparisons, here is a short and simple one.
You main decision factor is your target audience. Do you want to support the Apple platform and maybe even Linux? Then use SilverLight.
If you're sure you only have Windows clients (Web and Desktop) you could use the more powerful WPF. But do write the WBA first so you don't run into permission issues later.
Hy.I am currently working on a application in windows forms c#.My application is almost finished but the design is awful,i mean is very simple.I've searched some things about WPF and i think is a very good way to improve my design...But my question is:For using WPF only for my interface..if i will make copy -paste of my code, and i will modify only buttons and colors....will my project continue to work?Or I should started from 0...?
Thank you
In general I would recommend to start from scratch. If you aren't doing a complicated architecture here and have simple event handlers for WinForms you can pretty much stick with the same structure in WPF.
Architecturally speaking it would have of course been better to isolate the business logic from the event handlers. In that regard you might want to take a look at MVVM (and the MVVM Light Toolkit) and Prism.
We have successfully put a WPF shim around one of our very large WinForms apps and hosted the WinForms parts inside of a windows forms host. This allows you to convert one part at a time. This might be a route to take if this project is bigger or you are not sure you will be able to convert the entire application in one shot.
If your win forms app is designed properly you should be able to reuse all but your UI code. In my opinion WPF is far superior to win forms and you should definatly consider using it but it will take some learning to get started, dont do thus if you have a deadline coming up soon.
I also recommend you to move to the MVVM and WPF anyway if your project it is not so big you can use only WPF for interface and copy and paste your code. But from architecture point of view using the MVVM pattern you can make better separation of the interface (View) and you logic (Model) if you will use MVVM in the future will be easier to maintain and change your application
After toying a little with the new Silverlight 4 camera features, and being really disappointed that these were not included in WPF, I looked at the Silverlight assemblies and found that they more or less delegate all work to agcore.dll.
Do you think it is a good idea to package agcore.dll with my WPF application, and copy/paste or rewrite all classes concerning cameras to WPF, to get these nice features there?
That particular approach isn't likely to work, unfortunately. There's a lot more to getting C# code to work with Silverlight than just referencing the appropriate DLL. Silverlight is actually a completely different implementation of the CLR, so you can't just call into agcore.dll from a WPF app and have it run.
If you need Silverlight features in your app, I can think of two ways to get them: (1) you could conceivably host a completely separate instance of Silverlight inside a browser control in your WPF app, though communication with that Silverlight instance becomes complicated (though not impossible); or (2) you could write your entire app in Silverlight OOB (Out-of-browser)/trusted mode.
You can try VideoCaptureElement in my WPF MediaKit. It will show a webcam in WPF. It does have a different API than the Silverlight webcam API, but it should have just as many features.
I have a project that i started as a WinForms application as that was the format i was confortable with at the time. I have since started dabbling in WPF an introduced some WPF UserControls (mainly grids) into my project and absolutely love them.
The question i have is, is there any real advantage to me changing the UI Project of my solution into a purely WPF project, and get rid of any WinForms?
I am fully aware that each format suits a certain environment, and you wouldnt be able to give a definitive answer without knowing more of the details, but i would like to know peoples opinions, and if anyone has done a silimar thing of converting an existing WinForms App into a WPF frontend, and any observations they made in doing so.
Thanks
Underlying the new features in WPF is a powerful new infrastructure based on DirectX, the hardware-accelerated graphics API that’s commonly used in cutting-edge computer games. This means that you can use rich graphical effects without incurring the performance overhead that you’d suffer with Windows Forms. In fact, you even get advanced features such as support for video files and 3-D content. Using these features (and a good design tool), it’s possible to create eye-popping user interfaces and visual effects that would have been all but impossible with Windows Forms.
WPF enhances features that appeal directly to business developers, including a vastly improved data binding model, a new set of classes for printing content and managing print queues, and a document feature for displaying large amounts of formatted text.
But if you’ve done a substantial amount of work creating a Windows Forms application, you don’t need to migrate it wholesale to WPF to get access to new features such as animation. Instead, you can add WPF content to your existing Windows Forms application, or you can create a WPF application that incorporates your legacy Windows Forms content.
Reference: Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, Second Edition
I want to start silverlight development inside an application which developed by WPF.
Actually we want to add silverlight featuretoan existing WPF project. what should we consider and how todo this
I saw Getting started with Silverlight development and it was not my answer
I mark this as a Community Wiki.
Please clarify your intent. What do you mean by a Silverlight feature ?
Silverlight is a subset of WPF, but is intended for a Web application (i.e. running inside a Web browser, using the .NET framework provided by the browser plug-in), while WPF is meant for a desktop application (i.e. running outside of a browser, using the full .NET present on the disk).
(there is the notion of running WPF inside the browser, but that is still using the full .NET framework).
"Adding" Silverlight to WPF doesn't make much sense because you can accomplish whatever you need to do in regular WPF for the most part. If you already have a WPF application you are enforcing windows and the full .NET client run time so you are going to get any deployment benefits.
I assume what you may be considering (since you mentioned XBAP) is to re-write or recompile your current WPF XBAP application into a Silverlight application? This way you get cross platform web deployment with the full Client run time requirement.
If this is the case then you would not be "adding" to your existing solution. It would be more an exercise in porting the existing application over to Silverlight. With SL3 this is less painful then before (and if SL 4 is an option it will be an even better experience).
My first step would be to simply create a new Silverlight application and begin moving your code over and seeing how far you get.