I have an application that deploys smaller applications.
Those smaller ones basically consist of an icon (not a form icon) and a notifyicon control that needs an icon as well.
My question is: How to embed resources in the small application and compile it using CodeDOM?
I need the icon from the "bigger" application (the one that compiles) as they would have the same icons.
Thank you in advance!
If what you are asking is how to embed resources in an assembly built with CodeDOM (which is the only thing it will do, w.r.t. resources) then see http://msdn.microsoft.com/en-us/library/system.codedom.compiler.compilerparameters.embeddedresources.aspx.
If what you are asking is how to create .resource files programmattically, this has nothing to do with CodeDOM (i.e. it's not code and not an executable). But, possibly http://msdn.microsoft.com/en-us/library/xbx3z216.aspx will point you in the right direction/
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.
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.
Is it a way to embed my User Control into Windows Explorer? Please tell me if you have any resources about this.
Thanks,
Weipeng
While you can, and there are a number of examples of how to do this. I recommend that you do NOT create shell extensions in managed code.
There are a number of reasons for this. For example, you now have to pull the entire managed runtime into the shell namespace. This means your explorer instance will use a lot more memory than is necessary.
However, the single biggest reason is that you cannot control which version of the namespace might already be in the shell process space when your control is loaded. See this article for why it's a bad idea.
how do I enable visual styles when my project is a class library and it's being loaded into a program that does not have Application.EnableVisualStyles() set. I have been struggling with this for 2 days now. This is in C# (I've seen some examples for older C++ and some things that may work for VB, but nothing has been clearly laid out for C# and if it's even possible).
I have tried to run Application.EnableVisualStyles() from my Class Library before creating any controls, but it seems that needs to be done before an Application.Run() is done, and I don't have control when an Application.Run() is called since this is going into a 3rd party app as a plugin (VMware's Virtual Infrastructure Client).
I have tried to create a manifest file and after compiling the class library I link in the manifest file to my ProgressBar.dll with:
mt.exe -manifest ProgressBar.dll.manifest -outputresource:ProgressBar.dll;2
Except this doesn't work. If I make a dummy Application that uses my ProgressBar class library and link the manifest to that Application's exe, then the visual styles come up (basically it's doing the long way of specifying the Manifest file in the Project Properties, Application section).
Right now my buttons look ugly, but the biggest thing that is irritating is that the ProgressBar control doesn't work in Marquee style. I'm very soon going to have to resort to making my own Marquee-style ProgressBar or just throwing in an animated GIF in it's place. With regards to the buttons, I guess I can start using Infragistics buttons in order to get a more consistent result.
Please and thanks as always!
How can you be sure that there are no controls created yet when you call Application.EnableVisualStyles? Created does not necessarily mean that the controls are also visible on a form.
Since you are working with a closed 3rd-party component I would invest my time rather in creating my own controls if the look and feel is that important.
You'll have to use the OpenThemeData Win32 api in your control:
MSDN: Using Windows XP Visual Styles
I created a pretty fancy winforms app for my company. We had a graphic designer create the GUI, which was a pain to implement, all graphical buttons, lots of layered backgrounds and logos, animations, etc.
But now my company wants to resell it under different brands. But since I mostly coded it well, I told my higher ups I could have a totally rebranded version done in under a week. Basically all I would do is change a bunch of settings in an xml settings file, swap out the graphics with a new set, and build.
Problem is if they want 5 or 6 different brands, I'd have 5 different builds to support (I really should be supporting 1, with diff templates)
The problem is its not easy (as far as I know) to swap out the images in a winforms app. I have all the graphical resources in a single folder, but once each file is entered into its respective image list or container in visual studio, the only way to get it to update is to remove it and re-add it, changing the source folder doesnt cause the embedded image to refresh. This would be incredibly tedious for each build, there has got to be an easier way.
Add On:
So after some further investigation, I am leaning torwards some sort of resx file editor. However the ones I have seen so far are more focused on translating strings to various languages, and are either very weak, or can not at all edit binary resources like bitmaps/png's. Though if you open a resx file in an xml viewer (I use notepad 2 with .resx set to use xml sytax highlighting) MS is kind enough to tell you exactly how each type is compiled (mostly variations of base 64)
I think your goal should be having "brandable" resource files; you're essentially localizing your application, except you just have a few different versions of English.
You can use ResGen.exe and ResourceManager to load an external resources file, so you could use 5 different "resources" files but keep your code base the same.
This post may also help...
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/b388c700-0e07-452b-a19e-ce02775f78a6/
Edit: BTW, I will second the comment that if you're going through a great deal of effort on this, consider WPF... Most of those "graphical" elements could possibly be done natively especially if it's gradients and stuff, not to mention the easy templating.
What I would do is just load all the graphics of the disk at start up from a folder and create any imagelists needed as appropriate, instead of doing this in the designer. If you are worried that someone would steal the graphics, then I would create a simple file format (possibly encrypted) for my graphics and a small simple app for you or the designer to use to convert into this format from regular files. Then it's just a question of swapping out this folder between different brands.
If most of your forms are similar (i.e. same logo, same buttons on the bottom, etc.) you can use visual inheritance on WinForms to define a set of "Base Forms" from which your actual forms inherit.
If you develop a set of "Base Forms" for each of your brands, each set in a separate assembly you can plug-in the needed work to generate a new brand is reduced to generate a new set of Base Forms.
Hope it helps
It's too late now, but WPF would have been a better choice than WinForms, as it is easier to skin.
However have a look at what DevExpress does for WinForms, as their controls have a skinning system. It is not too hard to swap a DevExpress winform control for a standard winform control.
I think you should be thinking about creating user controls for the dynamically replaceable areas of the form. At runtime, you could swap out one assembly out for another.