I wonder how to best develop a plugin framework where you can develop plugins with both C++/MFC and C#.
The Host Program is an existing program developed in native C++/MFC. To extend the functionality of this program, we have so far developed separate programs in C++/MFC and C# that run as separate applications or windows services. These programs are now communicating with the host application via files. This is obviously a rather clumsy method, and we therefore wish to bring them under a common plug-in framework.
Each program also has a separate management of settings. We therefore want each plugin to expand the settings window in the host application so that all settings can be managed in one place. How can we do that in a flexible and easy way?
(...) we therefore wish to bring them under a common plug-in framework. (...)
You can do that by creating a set of COM interfaces in a type library that you can wrap in a C++/MFC dll project. Then from either C++ or C# you can import this type library and create new COM classes that implement the predefined interfaces. Two disadvantages of these approach are: 1- That your main application will need to know the class IDs somehow to create instances of the COM classes. 2- Your plugins will need to be registered on the system or you will need to provide manifest files.
(...) We therefore want each plugin to expand the settings window in the
host application so that all settings can be managed in one place. (...)
This one is a bit more tricky, but you could try having a tab control with one tab for each plug-in, then pass the window handle of the corresponding tab to each plug-in during initialization, and then use that to place an ActiveX control on it. Creating ActiveX controls in MFC is well documented, and there is a sample project here for doing the same in C#: CSActiveX Sample
Related
At a broader level, I'm converting a MFC application (MFC 6.0) into Windows Forms application (Visual Studio 2013). I read certain blogs that describes that this conversion is possible. By this conversion I can re-use code written in MFC, only I will need to create UI. However I will need to understand the previous code and may need to re-write it a bit.
I got the motivation from here and here.
I have performed following steps so far.
Opened Visual C++ 6.0 project in Visual Studio 2013.
Build it successfully.
Then added CLR support to it, and fixed errors.
Added a Windows form, and added controls to it. As mentioned here.
Added functionality and build it successfully.
Now when I run this application, then it still point to old MFC window.
I'm missing certain settings which will change the rendering window from MFC to WindowsForm. What am I missing here?
Addition to that, I see problem with this approach as described by #Roger in comments, and I understand that. So, I wanted to know for any tool/utility which may convert legacy code into C#. Does such utility available?
TIA.
The code you are referring to seems suitable for amending a MFC application with a few forms as child windows to make use of .NET features. However, the main window is another story. You wrote the application is huge, so I suppose you don't want a simple form as your main window and rather have some kind of MDI interface in mind. If you replace the CMainFrame in the legacy MFC application, it just doesn't make sense to maintain an old CWinApp class. Anyway, if you are hell-bent on going down that path, you may want to have a look at an old CodeProject articel (.NET1.x, .NET2.x) to get a better grasp at the whole concept.
But as Roger already suggested, it would be a wise choice to find a nice GUI framework, perhaps even WPF instead of WindowsForms, and do a GUI rewrite -- especially if one part of the motivation for the conversion is to move to newer UI concepts. If your C++ program logic is well separated in your MFC project, put it in a COM server and make use of interoperability.
Is there way to reference or open a page in the windows store app built using javascript template from a C# project template?
UI from C# and JavaScript apps aren't able to interact with one another directly on the project level. Although you can create a Windows Runtime Component in C# or C++ and use it from a JavaScript app, there still isn't the ability to share UI.
The only want to host HTML/CSS/JS in a C# app is through a webview control. You can interact with the JavaScript in the webview via its InvokeScriptAsync method, and the JS can raise events through window.external.notify, but the JS won't have access to the WinRT APIs like a JavaScript app does.
One app can launch another, of course, through either file or protocol association, but that's a different matter than building different parts of a single app with different technologies. Within that scope, a JS app can again use non-UI WinRT components, and a C# app can host a webview. Those are really the options.
I have a win form application and i'm trying to run it inside the web browser,i rummaged through web and found some links:
I tried this link:Embedding a .NET WinForms Application in an Internet Browser Using WPF
,this works fine but the problem is that the end-user has to install dot net frame work for running the application.
I found another link here for running a WinForms Application Inside Web Browser,with Visual WebGui development framework.
Has anyone had any experience with WebGui?
Well, Visual WebGui is web over ASP.NET. Its developing experience is the same/similar to that of Windows Forms using the Visual WebGui designer integrated into Visual Studio. You do your code behind just the same as you would on Windows Forms and the WebGui runtime transforms it into HTML5/CSS/JS.
The efforts needed to convert your Windows Forms application to a equivialend Visual WebGui web application will depend on the (3rd party / .NET) components used in your Windows Forms application. The Visual WebGui API is farily similar to that of Windows Forms, so in some cases you can add a few references to WebGui specific assemblies and then to a search/replace for a couple of namespaces. There are of course some differences, as these are two different platforms, but the developing experience is quite similar to Windows Forms.
winforms is not web. Web is Web.
Web means HTML + something (usually JavaScript, CSS and probably jQuery or such).
1 - If you need a web application, and want to do it with .Net, create an ASP.Net Application.
2 - If you need a Windows application (Desktop), create a WPF application.
3 - If you need a Windows 8 "Metro" style application (a.k.a Windows Store App), create a WinRT XAML application.
4 - winforms is completely useless. Forget that.
If your customers don't want to install any version of the .Net Framework, your only option is #1.
A winforms application will NEVER be a web application, regardless of any hacks you do to make it run inside a web browser.
an XBAP (WPF Browser Application) is also NOT a web application. It's just a regular WPF client application that does not have it's own window.
Edit:
If you did things the right way (that is, maintaing separation of concerns and putting application logic in Controllers or ViewModels instead of the horrible code behind practices most winforms developers are generally used to), It should not be that hard to reuse your application logic and create a new application (web or otherwise) while maintaining the Data Access and Business Logic layers intact.
I think this question is very similar to this one:
Is it possible to convert a WinForm to a WebForm in .NET?
As mentioned before, the only way to run the application "as is" inside a browser will be through the use of some activex control and that would require IE + .NET Framework.
There are tools that you can use to automatically migrate the application to the Web, but there will always be some manual effort involved and it won't be the same as building the application from scratch as a web app.
In my limited experience with Visual WebGui, it is pretty cool technology. In simple terms, as I understand it, you can use the Windows Forms development IDE to create an HTML5-compliant ASP.NET client/server web application... not just a web site or page, with a look and feel very much like a Windows forms desktop application. It does this by converting Winforms controls to jquery code on the client side, and stores most of the executable code on the server side.
I've used it to create simple applications for testing purposes, and there are a few caveats. First, to create a "pretty" website, you need to rethink the Winforms layout to make it web-like, with headers, sidebars, etc. It's a different paradigm, and users expect certain things on a website. The good news is that this adjustment can often be done fairly easy by simply manipulating controls; i.e. a Panel control can become a container for a sidebar or header. You can also create "themes", which are like skins for the controls to modify the appearance.
Another consideration is that events for things like popup dialog boxes behave differently in a web environment. In Winforms program execution halts until the user clicks an "OK" button or something. Within Visual WebGui, all the execution happens on the server side; thus, program execution would continue without waiting for user input. This can be handled by creating a Form.Close handler for the popup box though. But these kinds of differences need to be kept in mind.
You also must consider object layout anomalies. Visual WebGui does a good job generally of mimicking the Winforms WYSIWYG benefit: Objects normally appear pretty close on the webpage to where you put them in the environment. But this isn't always the case; you need to play around with object padding, margins, etc. sometimes to get the right layout. Still it is often much easier than tediously changing spacing with CSS or div objects.
Thinfinity VirtualUI allows you to do so by adding a small line of code to your C# application so it can then be accessed from any OS and device via an HTML-able browser.
https://www.cybelesoft.com/thinfinity/virtualui/web-integration-for-windows-apps/
I've used VWG but it's not really an option anymore. One option not mentioned here is WiseJ, a proprietary framework which is still under active development and support in 2022. And it is fairly straightforward to convert a WinForms app to WiseJ, or begin using WiseJ like you would WinForms.
They are located here: https://wisej.com
I would like to run a shell window manager kiosk-style WPF app that is full screen and contains in it other WPF apps.
Each WPF app is a project of it's own in my VS solution, what are the best practices for loading an instance of the other apps into my shell app and (preferably) confine them to certain bounds within the window manager.
I would try to rethink your design.
Instead of trying to load "other WPF Applications", it would be far simpler to load Windows, or potentially even better, UserControls, from the other assemblies (projects/solutions) and display them directly within your Application.
Extensibility like this can be accomplished fairly easily via MEF, which is built into the framework. This would allow you to define contracts that can be loaded dynamically in your main application, and used to build the functionality as needed.
I have recently started on Windows 7 app development, and I am stuck on the problem described below. Any help is greatly appreciated!!.
I am writing a WP7 class library function, which will be called from a Windows phone application. I want to be able to show a new screen to the user, after the function call has been made, invoked from the class library function. I also want this screen to be integrated with rest of the application UI properly. Like for ex., Clicking the back button on the UI screen, should take me to the UI screen that was present, before the call was made.
This WP7 class library has to be linked as a compiled library with the windows phone application. So keeping that in mind, I have following two questions.
1) Is it even possible, to launch a UI screen from a class library in Windows phone 7? If not, what else I could do here?
2) Is it possible to integrate this screen with rest of the application UI flow as described above.
Obviously you can include XAML pages in your library. To do that you have to include .pdb file which is generated along with the .dll for your library class. Copy both the .dll and .pdb file to your project and add reference to the .dll.
1) Yes. If you ever programmed Win32, then I understand your concerns. Handling UI in a dll was a bit problematic.
First to the class selection:
Popup class can be used to overlap current screen content. Its basic disadvantage is that it is not HW accelerated, hence unsuitable for complex screens or animations.
A better solution might be to store PhoneApplicationPage in your library (assembly). The result is the same as if the page was defined in the application assembly. This article describes how to navigate to another assembly.
When you navigate to another page (which is incidentally stored in another assembly), there is no shared UI context such as the main application window in Win32. The pages themselves are fully independent. URI of the first page is written in the manifest file. (Part of the xap file.) The application decides when to go to another page. Same as for browsers.
From the technical point of view:
Your class library produces an assembly (dll). This dll contains a) code (similarly to old good Win32 dlls), b) Xaml (exact copy of the Xaml code used in your library). It is the same as for your main assembly.
When you add a reference to the class library, that dll will be added to the xap file, i.e. to the installer. Go to your bin folder and look into the xap file. It is trivial as it is just a zip file.