I have two versions of a Windows Forms Application and can't figure for the life of me how to get a particular GUI behavior to be the same without copying the entire code (which is an obvious no-no).
Here is a visual comparison:
The left one is the one I want to fix so that it looks like the right one. Notice how the ToolStrip looks as if it contained an extra ToolStripDropDownButton, or some property or style I don't know about was set to make it look like that.
I've been diff'ing like crazy and couldn't find what differs. Any ideas?
Got it. In the left side case, the button was "overflowing". Its size was too large to fit the toolstrip and thus it was collapsed like that. After adjusting the button's size in the left side, all was good.
I found out what was going on after reading basic stuff about toolstrip controls here, in the "Using the CanOverflow and Overflow Properties" section.
Related
I have inherited a large MFC application which contains a CComboBox subclass that overrides OnPaint. Currently it does all its drawing by hand (with lines and rectangles), and renders a combo box that looks decidedly Windows 98-style. However, it otherwise works great and provides a lot of useful custom functionality that we rely on, and rewriting the entire control is probably not an option.
I would like to modernize it so that the OnPaint draws in Aero style where available (falling back to the old code when modern theming is unavailable). I've done this with some other custom controls we have, like buttons, and it works great for our purposes. I know there are some tiny behaviors that it won't get right, like gentle highlights on mouse-hover, but that's not a big deal for this app.
I have access to the CVisualStylesXP ckass, so I've already got the infrastructure to make calls like OpenThemeData, GetThemeColor or DrawThemeBackground pretty easily (via LoadLibrary so we don't force Vista as a min-system). Unfortunately, I don't know the proper sequence of calls to get a nice looking combo box with the theme-appropriate border and drop-down button.
Anyone know what to do here?
Honestly, I don't know why they originally tried to override OnPaint. Is there a good reason? I'm thinking that at least 99% of the time you are just going to want to override the drawing of the items in the ComboBox. For that, you can override DrawItem, MeasureItem, and CompareItem in a derived combo box to get the functionality you want. In that case, the OS will draw the non-user content specific to each OS correctly.
I think you best shot without diving in the depth of xp theming and various system metrics is take a look at this project: http://www.codeproject.com/Articles/2584/AdvComboBox-Version-2-1
Check the OnPaint of the CAdvComboBox class - there is a full implementation of the control repainting including xp theme related issues.
Not sure if it's the same situation - but when I faced this problem (in my case with subclassed CButtons), solving it only required changing the control declaration to a pointer and creating the control dynamically.
Let's assume that your subclassed control is called CComboBoxExt.
Where you had
CComboBoxExt m_cComboBoxExt;
You'll now have
CComboBoxExt* m_pcComboBoxExt;
And on the OnInitDialog of the window where the control is placed, you create it using
m_pcComboBoxExt = new CComboBoxExt();
m_pcComboBoxExt->Create(...)
Since this is now a pointer, don't forget to call DestroyWindow() and delete the pointer on termination.
This solved my particular problem - if your control is declared in the same way, consider giving it a try.
I add my menu items shortcut keys, but they are poorly arranged.
and I need to make it like this:
Ah, I think I finally figured out how to do this (it had been puzzling me for quite some time how you'd gotten the two different screenshots...). It turns out there are two ways that you can instruct Windows to align shortcut keys in a drop-down menu.
The first (and probably most standard) way is to insert a tab character (\t) in the string corresponding to the menu text. This produces the bottom example shown in your original question, the one where all the identifiers are left-aligned and some overhang slightly. This is the standard in almost all Microsoft applications, and the only option that I knew existed until a few minutes ago.
Sample resource string: &Print…\tCtrl+P
The second way is to replace that \t escape sequence with \a in the resource string (which, yes, strangely enough would normally indicate an alert bell). This causes Windows to right align all of the shortcut key sequences in the menu, producing the example illustrated in your first screenshot. This does produce a menu that uses screen space more efficiently (it's smaller), but this comes at the cost of a neat alignment of each of the shortcut key sequences down their left-hand margins, which I think makes for slightly easier readability.
Sample resource string: &Print…\aCtrl+P
So if you want your menus to look like the second example in your original question (Yes, I've confusingly arranged my samples backwards. Sorry), you need to delimit the shortcut key sequence with a tab character (\t) in the resource file containing your menu item text strings.
The strange thing is that you claim to be using .NET WinForms, which handles all of this automatically (saving you from the pain of messing with resource files). I know for a fact that it inserts tab characters, and all of the menus I've ever seen it generate do look like your second example.
The best thing to do is switch your menu to the old MainMenu control included with earlier version of the .NET Framework. (To do this, you'll probably have to right-click on the Toolbox and add the control manually—it isn't there by default on later versions of Visual Studio.) This will ensure that you see the alignment behavior you expect, consistent with all of the standard Windows applications like Notepad. It also produces menus that look like the native operating system menus (in Vista and 7, they are painted blue) rather than the amateur-looking owner-drawn menus produced by the MenuStrip control that are completely out-of-place in modern versions of Windows.
Microsoft's official documentation does confirm that the MainMenu control is still supported for future use, so there's no reason to fear using it in your apps. I highly recommend everyone use this instead:
Although MenuStrip replaces and adds functionality to the MainMenu control of previous versions, MainMenu is retained for both backward compatibility and future use if you choose.
They are 'right' aligned, as you can see. (No pun intended).
This is default behaviour for a menu. You'll need custom drawing to do it differently.
Every OS has it's particular look and feel, and I guess that you have to have pretty good reasons not to honor how every other application on the windows looks. I guess you will either drop the issue, or will extend the menu with OwnerDrawn items.
Here is the overkill article on the subject.
As you know, the built-in themes all define styles for the standard controls such as the TreeView control. We're trying to create something that looks an awful lot like a TreeView but isn't actually one, nor is it a subclass of one. It just has parts that we want to look like one for consistency.
For instance, our control too has a selected item whose background we'd love to match to the appearance of the background for the selected item in a TreeView (or more accurately the TreeViewItem) for the current theme. (You can't simply use highlight color as the themes have nice gradient brushes and borders, not just a solid brush.) Same with our expand/collapse togglebuttons. We want them to look just like the ones used in a TreeView for the current theme. (i.e. Sometimes a triangle, sometimes a box with a '+' in it, etc.)
Now while we can simply rip open Expression and copy the styles ourselves (or at least the parts that we need), we'd have to do that for each and every theme that MS provides. Plus, that wouldn't handle newer themes. And in a purest standpoint, that's duplicate styling information which just sits wrong with me.
Also, if someone styles the actual TreeView(Item), we want to pick it up as well. Since the parts that we want to style are required parts of a TreeView, we feel pretty confident that they're in there somewhere style-wise.
Not even sure what I want to do is possible but if anyone knows, they're most likely here on SO!
Yet another question close to a month old without even a comment. Very odd for the SO community to not chime in at least once! Guess it's not possible.
Well, what we ended up doing was using 'Show Me The Template' (Google it) to get the templates for the part (we don't have Expression), then manually managing them ourselves instead of using the built-in styles. NOT at all what we wanted to do since we don't know of a way to get the nice gradients that are defined in the system already without duplicating them, but the end result does match perfectly so there's that. As such, this too is getting marked as the answer. I'll gladly change it if someone else actually gives me one that works (or is close enough! Just need something people! Feel like I'm posting in a vacuum here!
I'm pretty green when it comes to WPF, so forgive me if this is an obvious question.
I'm trying to modify an existing code base that is using the Divelements SandRibbon libraries, but am finding that the GalleryButton control doesn't behave quite how I'd like. What I'd like to do is change the way GalleryButton arranges the image and label, but keep the default 'look' for all triggers such as mouse over etc.
Is it possible to apply a ControlTemplate to some parts of a control but not others? I want to specify that the GalleryButton displays its 'Image' and 'Text' properties differently than the defaults, but not touch anything else.
Unfortunately no -- it's all or nothing. However, one solution I've used before is to simply sublass the control and alter the layout in code behind in OnApplyTemplate.
I asked a similar question about this previously, but I did not specify that this needs to work in Partial-Trust mode. Unfortunately both correct answers (using UIElement.BitmapEffect or UIElement.Effect) are not allowed in Partial-Trust, because it requires UIPermissionWindow.AllWindows.
Does anyone know of a way to do something similar to the OuterGlowBitmapEffect in a Partial-Trust app?
If you need a rectangle outline, you can attach an Adorner with a simple rectangle in it. It's not going to have the glow effect you are looking for, though.
If you need a non-rectangle outline, you can still use Adorner, but you also need to specify opacity mask, based on a visualBrush on your object. You will also have to make the adorner a little bit bigger than the source visual, to make it look like it surrounds the object instead of overlapping it.
If you want to go fancy, you can encapsulate attaching the adorner in an attached dependency property and just attach it to any visual you need to outline.
If you don't want to bother with adorners, you could have two separate templates for you visual - one with the outline pre-created and one without and switch them as needed. However, this requires you to know upfront what cvisuals you would need to outline and what is their style. Granted, you can make it quite flexible with data binding, but still it's not a generic solution to your problem.