I have a Windows Forms application that does not include a title bar, and on Windows 7, the taskbar shows the value from AssemblyTitle, rather than the value from the form's Text property. How can I change this value dynamically?
Thanks!
From your comments, I think you're referring to the "jump list" for the program, which includes a program title (if you click on it, an additional instance of the program is launched). My understanding is that what you're seeing is the default behaviour for all applications, regardless of the visibility of the title bar on your Form.
I tried to change this on a program I was writing and came to the conclusion that (at least within managed code) it cannot be done - Win 7 takes the value of the FileDescription in the executable (AssemblyTitle is a proxy for this in Win Forms apps) and uses this. As far as I know, assembly attributes cannot be altered for a running assembly and I'm not sure Windows would notice a change and update the jump list even if you could do it.
There is a managed wrapper for the Win 7 API (the Windows API Code Pack), and although there is a class for manipulating Jump Lists, I found nothing within it to override the default behaviour for this particular aspect of them.
Edit:
Looking more closely into the native API (as opposed to the managed Code Pack wrapper), I couldn't find any functions but I did discover this MSDN blog entry. Just under the second diagram (which defines the application title as part of the "Taskbar Tasks" section) and the Windows SDK quote, there is a list of activities developers can perform and it includes the following:
As developers we have no control over
the Taskbar Tasks.
So it looks like it's just not possible - this section of the Jump List is controlled exclusively by the OS.
Related
WPF and Windows Forms Interoperation
Description on MSDN:
In a WPF user interface, you can change the z-order of elements to control overlapping behavior. A hosted Windows Forms control is drawn in a separate HWND, so it is always drawn on top of WPF elements.
*But I would like to know there is no private way to solve it?
No, this is known as the airspace problem (because WinForms elements take all of it).
There was supposed to be a fix around .NET 4.5/4.6 but it never made it to production (source; there are others if you google it). There has been no word as of yet that Microsoft plans on addressing it.
This article might help with ways to get around it: MSDN
My first recommandation would be to replace the Windows Form control by an equivalent WPF control.
Second recommandation would be to accept the limitation and do not overlap any WPF control over the Windows Form control.
In some case, you might be able to use multiple top-level Windows to work around the limitation. You then have to write some code to properly synchronize the location or the apparent activation state of Windows...
I have never done that between Windows Form and WPF but I have done 2 top-level windows in Windows Form so that part of the UI could be semi-transparent (the purpose was to be able to overlap another application (maybe a PDF viewer) so that we can "copy" curves from existing charts).
I want to make a menubar like window taskbar in C# but I'm wondering how can I make the form stay on the top of the screen and other program will not taped over it just like the window taskbar and when the mouse hover on a icon it will show a form like this:
I have made it like this:
And This is what I want
Windows has a facility for this, allowing you to basically create pseudo-taskbars that dock to the side of the screen and are always visible. It was used by the Office team (possibly publically documented for the Office team?) a long, long time ago to create a desktop toolbar.
Anyway, they are called Application Desktop Toolbars (or "AppBars"), and the documentation is here. To register one, you call the SHAppBarMessage function with the ABM_NEW message. Complete sample code is available in the linked documentation, unfortunately it is in C++.
To use this from a C# application, you will have to P/Invoke. As far as I know, it is not wrapped by the .NET Framework anywhere, probably because it never gets used by anyone anymore. This CodeProject article appears to have the necessary P/Invoke definitions written out. I can't vouch for their correctness, but armed with the documentation and that as an example, you should be able to cook up a working demo.
There is another CodeProject article here, written by Arik Poznanski as part of a series on using shell features from C#. It looks much more thorough, probably more than you need.
Set the property Form.TopMost unless you have other programs creating topmost windows. Doh!
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.
According to Microsoft template the entry point of Windows Phone app is MainPage.xaml. I manage to change it to *.xaml page, but how to get rid of those .xaml pages and write only C#. In windows Forms it was quite easy, but what about Windows Phone ? If I just change the default task to be .cs file, it doesn't run.
Unlike in WinForms there is no concept of an application's main entry point not corresponding to a visual page represented by XAML (in this case, as you pointed out, the default is MainPage.xaml). The idea being that this wouldn't make sense since there always has to be a visual portion to a Phone application. While you could potentially write the same thing purely in code it's not something that is directly supported.
An application has the ability to run in the background via Background Agents (see http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202942(v=vs.105).aspx), but it still needs the visual portion of the application to install the Agent and to be accepted onto the Store.
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