I have a MDI based rather huge application that has plugin Architecture.
The plugins MFC unmanaged DLLs that bring many unmanaged dialog(CDialog base calls).
I am planning to initially only build the main GUI framework in WPF and keep the plug ins still in MFC, and have Managed wrapper dll which enables me to call this dialog in a managed application.
Slowly change 100+ plugin we have over the period of time.
I would like to have new application also a MDI with docking support. So I am planning to use 3rd part libraries from ActiPro and Syncfusion.
My question is
1) How can I add / remove menu items in a WPF application based on the need of the plug in that is loaded ?
2) How will I able to dock my MFC Dialogs in a WPF application as if they were created using WPF.
Any help is greatly appreciated.
Shashi
Related
This is a question about design approach. I have limited COM experience and a little WCF experience. My constraints are given by the application environment, but I have some design flexibility.
From within a VB6 dll, I need to start, and communicate with, a WPF application. The WPF application is currently an exe, but I could make it a library if that helped. I would like to provide two way communication between the VB6 dll and the WPF application. I have some flexability to adjust the design of the VB6 dll.
I'm developing C# using in VS2010 and .NET 4.
How many components should I use? Can I start the WPF application In-Proc with the VB6 dll? Should there be a third component between them? Can COM+ play a helpful role? Do I have to make the entire WPF application COM-visible? Is there a down-side to doing this?
I'm looking for a design approach that I can prototype. I'm willing to research the details.
I would
Create a Web Service from the WPF application, using WCF. I would abstract out those aspects of the WPF application which should be accessed remotely. This would explicitly not include any of the user interface code.
I would create a simple class library project, and use "Add Service Reference" to add a reference to the WCF service.
I would make the methods of the class library COM-visible
I would call those methods from VB6
This has the benefit of removing any considerations of user interface from the equation.
Out of the options available I like the COM option more than the 'start another process' option for the simplicity that the inter 'application' communication will be via method calls rather than WCF or anything similar.
I am assuming that your VB DLL lives in a window'd process and not a service or web application. You would only need to mark any exposed types as COM visible, that is the classes, their argument and return types.
You may have to wrap your WPF UI inside the windows forms ElementHost [1] but I'm not sure, try it and see.
I'm not sure if you saw this [2] in your search, it sounds do-able but unsupported, ok as long as you don't have too much going on.
[1] http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.elementhost.aspx
[2] http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7555ba6a-1359-4dfe-aa23-c31a8f121142/
I work on an application primarily written in VB6 but most of the recent code is written in .net with UI components built in WPF and some WinForms. Datasources for this application are WCF, MSSQL server, and a propritary unix based server. All the WCF calls are made from data access components referenced by the .net UI components.
You can host WPF in VB6 windows or other container controls. Start by getting the Interop Forms Toolkit and build shell user controls to host your WPF controls.
To be able to host WPF in these controls you need to build a WinForms usercontrol which contains a ElementHost, which you can set the content to your WPF usercontrol.
WPF Usercontrol inside an Element Host inside a
WinForms usercontrol inside a VB6 usercontrol or
window
The interop toolkit will want to build VB.Net code but you can do it in C#, although I have not tried this. The usercontrols created by the interop toolkit will be exposed as COM components which you can reference VB6 by adding them as components via Project > Components and then you will find them in the toolbox.
In terms of data sources (WCF, databases) etc, you should build all your data access in .net components referenced directly from the UI components, don't try to call back in to VB6 libraries, you will probably just create a mess.
In my application I also have a configuration section which I call from the VB6 application startup which sets up an IoC container for all the .net components.
From a best practice approach I actually would recommend rewriting your VB6 code to .net and putting VB6 out of the picture. If this is not an option then you have a number of options, my explanation is just one of them.
I want to integrate two existing applications into one. One of those apps is built on Windows Forms and the other on WPF.
Is it possible to achieve this?
WPF supplies the WindowsFormsHost class that allows you to host WinForms controls inside a WPF window; conversely, WinForms supplies ElementHost that allows you to host WPF controls inside a form.
Unfortunately how well things work out is highly dependent on exactly what you are doing, last time I checked there were more than a few rough edges. For more information, definitely start from this MSDN page.
If you want to have "independent" WPF windows and WinForms forms inside the same application, you will have to make both frameworks "share" some code in your UI thread's message loop. For a primer on how to do that, see here.
There are various classes to help you with this.
For hosting Windows Forms controls in a WPF Window, you can use the WindowsFormsHost class. For hosting WPF Controls in a Windows Forms Window, you can use the ElementHost class.
You can look here for mor information on the subject (windows forms section):
http://msdn.microsoft.com/en-us/library/ms753178.aspx
I am trying to integrate WPF into a legacy MFC application. I am unable to include the /clr switch to mix managed and unmanaged due to the restrictions of other projects in the solution. I need the WPF window open up as a child window in the main MFC application. I have been investigating different ways for the past two weeks but have hit roadblock with every implementation try. If anyone has successfully integrated this type of implementation, I would appreciate some direction. I have been able to integrate with a Win32 app, but could not translate this to an MFC app. Thanks everyone.
I believe that WPF requires .NET, therefore what you need is to create a separate DLL or EXE for the WPF parts. hat new project could be the container for .NET code and your main MFC would launch this separate project.
You can write a WPF front end that launches C++ apps with the desired command like switches, similar to what Visual Studio 2010 is doing to compile your code and show the results in the output pane. In this way you can avoid having to hack message loop code to support both frameworks .
You may show your Dialog using a COM interface
I have a monster of a win32 application with GUI based on a mixture of MFC, WTL, user32 and a few other technologies. I need to add another top-level window and I would like to give WPF a chance.
Could you help me identify the steps necessary to host a WPF window in win32 app? Details are welcome.
I'm sorry for giving trite answer, but I can't explain it better than it is explained at MSDN:
Hosting WPF Content in a Microsoft Win32 Window, Walkthrough: Hosting a WPF Clock in Win32. You may also be interested in WPF Documentation samples at MSDN Code Gallery, or alternatively look at their mind-mapped version.
Keep in mind if its a top-level window you're after (and not a window embedded within another window) you can simply create a new Window-derived WPF window from managed C++.
I.E., either 1) create a C++/CLI library that references your WPF library and call that from your unmanaged code or 2) add the /clr library setting (not recommended, due to performance implications) and add a reference to your WPF library. Then simply call:
#include <vcclr.h>
gcroot<MyWindow^> newWin = gcnew MyWindow();
newWin->Show();
I'm attempting to host an ActiveX control in a WPF app. After attempting to use existing info on the web and here, I've hit a dead-end.
I need to use an ActiveX control provided to communicate with a UV power meter. They provide an application that registers and uses the control and even includes some useful demo apps. I stripped out the OCX file and put it here if needed. You won't have the power meter to talk to, but the app and demos will still load the ActiveX control successfully.
I created a simple Windows Forms application. I was able to bring the ActiveX control into the toolbar, drop it into my form, and everything is fine. The demo apps they provide do this as well.
However, getting this to work in a WPF environment is another story. The control can't be added to the toolbox and "dragged" into the app.
So far I've tried two techniques:
Technique found here. I am able to add a reference to the control, but then I enter namespace hell. The xmlns:ax namespace it suggests making cannot find the information. Here's my attempt based on what the object viewer tells me: xmlns:ax="clr-namespace:OphirUsbXLib;assembly=Interop.OphirUsbXLib"
Technique found here. This is essentially to create a new project that creates a library based on Windows Forms, which contains the ActiveX control (yikes). I am able to add the Windows Forms Host, but I cannot get access to the ActiveX control within. I can make the control public, but I still cannot call methods etc. This doesn't look like the right solution.
In short, I have an ActiveX control that works beautifully in Forms, but is a real bitch to get working in WPF.
Any insight is appreciated!
In this situation I would consider making a WinForms usercontrol which wraps the ActiveX control you are trying to use.
You could make public properties and methods which expose each of the required properties and methods on the ActiveX control, and then host this WinForms UC on the in a WPF WinFormsHost control.
I have already done something similar to this, in reverse, hosting a WPF UserControl in a WinForms UserControl, then hosting that on a VB6 Form in a legacy application.