jfo's coding : Windows Forms

High DPI - it's an everyone thing.

jfoscoding — Sun, 11 Oct 2009 23:07:00 GMT

As larger displays are becoming more popular, they're increasingly being used in places like the livingroom. And if you've ever tried to read text across the room with the default DPI setting, you'll find you may need a pair of opera glasses.

In Windows 7, if you're using a larger display, the OS will automatically adjust for you, in the hopes that you will be more likely to be able to read text.

From this we see that there is a real end user benefit to tap into here. It turns out that there is existing infrastructure in Windows called “High DPI” which can be used to address this. High DPI is not a new feature for Windows 7, but it was not until Vista that the OS user-interface made significant investments in support for high DPI (beyond the infrastructure present earlier). To try this out in Vista, rt. Click desktop -> personalize and select “Adjust Font Size (DPI)” from the left hand column. Our thinking for Windows 7 was that if we enable high DPI out of the box on capable displays, we will enable users to have a full-fidelity experience and also significantly reduce eye strain for on-screen reading. There is even infrastructure available to us to detect a display’s native DPI so we can do a better job of configuring default settings out of the box. However, doing this will also open up the door to expose some issues with applications which may not be fully compatible with high DPI configurations. - Engineering Windows 7

It may be worth a look to see what your app looks like in 120 DPI. In both windows forms and WPF, good use of the AutoSize features usually accomodates most scaling issues. It can be tricky to set up, but once it works, it usually works well.

Windows Forms lets you set everything in pixels, and then during the loading process, it uses the AutoScale feature to magically multiply whatever you said by however bigger and/or smaller things are supposed to get. How much bigger/smaller things get is best calculated by taking the font size of the Form when you designed it (which is what AutoScaleBaseSize, AutoScaleDimensions are), then taking the new font size as currently run on the system. The percent difference in size is used to adjust the size/location of controls.

For windows forms, check out the "AutoScale" section of this layout FAQ for tips as to how to use AutoScaleDimensions.

WPF uses Device Independent Units, which is a fake unit that makes you always think you're drawing in 96DPI. When it goes to render to the screen, it translates the DIU to DPI doing the math under the hood for you. Charles Petzold does a good job explaining how the math works. For the most part this system works well, though you need to know the tricks for image rendering and getting lines to draw crisply.

Note this also means when doing WPF->Win32 interop, you need to translate back to the device coordinate system. E.g. a WPF button that's set to Width=75, Height=23 is set to 75x23 DIU, not 75x23 pixels. To translate back you can use Visual.PointToScreen or PresentationSource.FromDependencyObject(dobj).CompositionTarget.TransformToDevice.

In either system, if you have bitmap artwork in your application, you may want to consider whether or not you want to use a separate larger image for this mode - as in high DPI, the image will be stretched larger.

If I have any more specific tips, I will be sure to post them!

Avoiding throwaway layout/painting/mouse code

jfoscoding — Tue, 08 Sep 2009 07:20:00 GMT

I’m not normally a Hungarian fanatic or anything, but it is quite easy to create “write once” layout/painting code. If there’s ever a problem with the math the code needs to be tossed out because it’s too confusing or too difficult to update.

I think we've all either seen this kind of code and/or have been guilty of writing it at one point... in the interests of reducing frustration for everyone I've got a few tips to write more maintainable UI code.

Label things what they mean

Instead of:
Rect r = new Rect(button1.RenderSize);
Consider something like:
Rect button1Bounds = new Rect(button1.RenderSize);

If it’s something not within the button’s coordinate system, then label it by the coordinate system it is in:

e.g. Rect button1BoundsInWindowCoords;

When creating transforms, consider labelling them in fromTo notation:

e.g. Transform button1ToWindowTransform = button1.TransformToAncestor(window) as Transform;

This helps you when you’re in the debugger – if you have “t” in your watch window you don’t know which transform you meant when you were writing your code. I get out a piece of paper and prove the math, and then I verify that my variables are as expected in the debugger. You can really only use this method if the variables mean something that can’t be changed.

Avoid UI “fudges” if possible. If you must fudge comment it!

Whenever there’s a fudge, you’re quite likely to be revisiting that code in a few days. Try to figure out why you need that extra 1PX and put it in a comment next to the code.

Define reference rectangles and work within them

If you only want to do something when something is in the first five pixels of your control, don’t be afraid to create and maintain your own rectangles. The good thing about reference rectangles is that you can draw them out and see if they are in the right spot.

Rectangle topDropZone = new Rect(0,0,this.Width, 25);

Learn the methods on Rect/Rectangle/Point/Size/Vector
There are a lot of built in methods that help keep your math tidy. It’s worth looking at the APIs in some tool or in MSDN to see what can make your life easier.

Here are a few examples from WPF/Silverlight (most are true of System.Drawing as well):

//Rectangle provides intersection/union methods
if (dropZoneRect.IntersectsWith(someOtherRect))
Rect selectedArea = rubberBandRect.Intersect(controlBounds);

// Inflate is very handy for increasing the size of a rectangle in all dimensions
Rect borderArea = controlBounds.Inflate(1,1); // x-=1, y-=1, width +=2, height+=2.

// Offset is very handy for adding to X & Y
Point startingLocation = new Point(10,20);
startingLocation.Offset(30,40); // adds 30 to x and 40 to y

// you can cast a vector to a point or size.
Vector someVector = new Vector(100,20);
Point somePoint = (Point)someVector;
Size someSize = (Size)someVector;

Got any tips?

How can I remember which order Margin properties are set?

jfoscoding — Tue, 08 Sep 2009 05:10:00 GMT

Often you can stare at a margin property "10,20,30,40" in XAML and be slightly confused as to which is which property. If I have to deal with a format over and over again I will come up with a trick to remember how to work with it.

My trick is to remembering Thickness/Margin is by saying "LTRB" as in "letter b".

Example: if we wanted to set the for a button margin like so:

Windows Forms
button.Margin = new Margin(10, 20,30,40); // L,T,R,B

WPF/Silverlight
button.Margin = new Thickness(10,20,30,40); // L,T,R,B
<Button Margin="10,20,30,40"/>

CSS
For completeness, this appears to be different than CSS, which is TRBL or (trouble).

margin:20px 30px 40px 10px;

VB6/Winforms interop

jfoscoding — Tue, 31 Oct 2006 20:42:00 GMT

Check out the Microsoft InteropForms Toolkit 1.0

This toolkit helps you bring the power of .NET to your existing VB6 applications, by allowing them to display .NET WinForms from within the same application. Instead of upgrading the entire code base, these applications can now be extended one form at a time. The goal is a phased upgrade, with production releases at the end of each iteration containing both VB6 and VB.NET forms running in the same VB6 .exe process.

Screencast available here: http://blogs.msdn.com/vbteam/archive/2006/09/23/768719.aspx

Josh seems to be having fun with Renderers

jfoscoding — Fri, 20 Oct 2006 07:55:00 GMT

It looks like he's put together a very convincing VistaToolStripRenderer, and promises a tell-all series of articles.

Stay tuned!

Workaround for disabled flyouts

jfoscoding — Fri, 11 Aug 2006 06:56:00 GMT

Frans ran into some trouble disabling parent menu items. Turns out they dont disable the evaluation of child shortcuts. This was an oversight on our part. That said, most applications remove flyouts that are not in-use so as to not taunt users with menus they can't click on. =)

Here's a quick workaround. Add this to your project and replace your ToolStripMenuItems with this type.

Hope this helps!

---

using System;

using System.Collections.Generic;

using System.Text;

using System.Windows.Forms;

namespace WindowsApplication51 {

/// <summary>

/// Workaround for disabled flyout menus still evaluating shortcuts

/// </summary>

public class FullyEnabledMenuItem : ToolStripMenuItem {

protected override bool ProcessCmdKey(ref Message m, Keys keyData) {

if (!IsEveryoneEnabled()) {

// store off the current state of enabled-ness

bool isEnabled = Enabled;

this.Enabled = false;

// process the shortcut

bool handled = base.ProcessCmdKey(ref m, keyData);

// restore the state of enabledness

this.Enabled = isEnabled;

// return the result of processcmdkey

return handled;

}

else {

// everyone was enabled

return base.ProcessCmdKey(ref m, keyData);

}

private bool IsEveryoneEnabled() {

if (!this.Enabled) {

return false;

}

// walk up the owning item chain until the top

ToolStripItem ownerItem = this.OwnerItem;

while (ownerItem != null) {

if (!ownerItem.Enabled) {

return false;

}

ownerItem = ownerItem.OwnerItem;

}

return true;

}

Win32 Activation and Focus

jfoscoding — Wed, 02 Aug 2006 09:53:00 GMT

For the most part, activation and focus work pretty darn well in windows, until you want to tweak something that doesn’t fit within the typical windowing model or roll your own menu.

Most folks don’t separate out activation and focus, but they are really separate things. Experimenting for a moment – if you bring up the run dialog (start->run) and tab over to the cancel button – a dotted rect indicates that the cancel button currently has focus. This rectangle goes away when you subsequently alt+tab to a different application. Separately, you may notice that the color of the window goes from dark blue (when the window is active) and light blue (when the window is in-active).

With that observation in mind, we could come up with a crude distinction between activation and focus.

Activation is the currently active top-level window.

Focus is the control in the system that will receive keyboard input.

Walkthrough – understanding the interaction of window messages

In the run dialog example, I have taken the liberty of capturing some spy++ output. I picked Spy->Log Messages, chose “windows of same thread”, dragged the finder tool to the run dialog and checked off the following messages:

WM_MOUSEACTIVATE – Occurs when someone mouse-s down on an inactive window. Sent to control being activated.

WM_NCACTIVATE – Occurs when the non-client area needs to be activated or de-activated (most commonly the title bar changes shades of blue). Sent to the toplevel window.

WM_ACTIVATE – Occurs when the client area needs to be activated or deactivated. Contains information about the other window being activated/deactivated. Sent to the toplevel window.

WM_SETFOCUS – Occurs when setting focus to a control. Sent to the control itself.

WM_KILLFOCUS - Occurs when a control is losing focus. Sent to the control itself.

I then alt+tab’ed to the run dialog and got the following output:

<00011> 001101DC S WM_NCACTIVATE fActive:True

<00012> 001101DC S WM_ACTIVATE fActive:WA_ACTIVE fMinimized:False hwndPrevious:(null)

<00013> 00080166 S WM_SETFOCUS hwndLoseFocus:(null)

00011 – WM_NCACTIVATE: The title bar was previously light blue; this message changes the non-client to be in an active state – the wParam of fActive tells us that the window should become active.

00012 – WM_ACTIVATE: This message activates the client area of the toplevel window. The wParam specifies the fActive, and the lParam specifies which other window in the system was previously active. This handle can be null and will be when the previously active window is not in the same thread.

00013 – WM_SETFOCUS: The cancel button is getting the focus in this case. When you get a WM_ACTIVATE, it is usually immediately followed by a WM_SETFOCUS.

When I alt+tabbed away from the run dialog I got the following output:

<00014> 001101DC S WM_NCACTIVATE fActive:False

<00015> 001101DC S WM_ACTIVATE fActive:WA_INACTIVE fMinimized:False hwndPrevious:(null)

<00016> 00080166 S WM_KILLFOCUS hwndGetFocus:(null)

00014 – WM_NCACTIVATE: The title bar is now switching from an active to an in-active state.

00015 – WM_ACTIVATE: The client area has now lost activation. Because the window becoming active is outside of the current thread, the handle of the window activating in the wParam is null.

00016 – WM_KILLFOCUS: The button has now lost focus. Because the window getting focus is outside of the current thread, the handle of the control getting focus in the wParam is null.

Finally I clicked on the run dialog, while it was in-active, and activated it.

<00017> 001101DC S WM_MOUSEACTIVATE hwndTopLevel:001101DC nHittest:HTCAPTION uMsg:WM_LBUTTONDOWN

<00018> 001101DC S WM_NCACTIVATE fActive:True

<00019> 001101DC S WM_ACTIVATE fActive:WA_CLICKACTIVE fMinimized:False hwndPrevious:(null)

<00020> 001501E8 S WM_SETFOCUS hwndLoseFocus:(null)

Messages 18-20 are the same as before, but there’s a new message, WM_MOUSEACTIVATE. This message goes to the control that was clicked on to ask whether it is interested in accepting the mouse down and/or activating the window.

Some other interesting functions

Since a windows message queue is per-thread, a lot of the notion around focus and activation is also per-thread.

GetFocus – returns the handle of the currently focused control on the thread.

SetFocus – sends a WM_KILLFOCUS to the old control, activates the new window if necessary and sends a WM_SETFOCUS to the new control. In Windows Forms this is wrapped in the Focus() method.

GetActiveWindow – returns the handle of the currently active top-level window within the thread.

SetActiveWindow - activates a top-level window within your current thread. If the application is not in the foreground, it sets what the active window will be.

GetForegroundWindow – returns the top-level window that is currently active on the desktop.

SetForegroundWindow – changes the top-level window that is currently active on the desktop. Not really – see remarks for restrictions. And why.

How can I prevent clicks from activating and focusing my window?

You can override the WndProc and handle the WM_MOUSEACTIVATE message. You can either let the click go through – which is MA_NOACTIVATE, or you can eat the click – which is MA_NOACTIVATEANDEAT. A sample of preventing clicks is here.

How can I prevent my window from getting activation and focus when shown?

In Windows Forms 2.0 there is a new property called ShowWithoutActivation – which you would need to override on the Form. In native applications you can use SetWindowPos with the SWP_NOACTIVATE flag or the ShowWindow with the SW_SHOWNA flag.

How can I get focus, but not activation to my window?

This is typically a menu-ing situation – you want to show a treeview or something in a popup window. I’ve talked a bit about the pain and recommendations here. The 2.0 framework supports this, I would recommend starting there rather than rolling your own solution.

Best practices with focus and activation (or rather, lessons learned the hard way)

Avoid manually changing focus when getting and/or losing focus. This usually proves to be error prone. Instead look for ways to prevent the focus from changing – preventing activation will usually prevent focus changes.

Avoid manually changing the active window. In most cases, it is not possible to activate a window that is not within your process. There are a whole bunch-o-rules in the remarks section.

The debugger can get in the way of debugging these issues by setting itself as the active window when hitting a breakpoint. Try using tracepoints, Debug.WriteLines or remote debugging.

Rule of thumb for System.Drawing

jfoscoding — Tue, 25 Jul 2006 18:02:00 GMT

A friend of mine ran into this the other day.

If you call a method to get a handle some sort of System.Drawing object, you may be creating an object that needs to be cleaned up through P/Invoke or some other function call.

Bitmap.GetHIcon - requires p/invoking DestroyIcon.
Font.ToHFont - requires p/invoking DeleteObject
Graphics.GetHdc - requires calling Graphics.ReleaseHdc

The MSDN2 documentation seems to be a lot more clear about this, so if you're accessing a handle, you might want to pop over there to see if there are cleanup instructions. You might also consider using the GDICounter and reading the background info on when to use Dispose.

Tim resurfaces with another control

jfoscoding — Sun, 23 Jul 2006 20:38:00 GMT

I enjoy talking to Tim Dawson quite a bit; we both know that making the decision to build your own menu is not one to be taken lightly. He's been busy lately.

How do I detect when the WindowState changes?

jfoscoding — Fri, 23 Jun 2006 17:53:00 GMT

Most of the time, you can get away with checking it in the Form.SizeChanged or Form.Resize event. If you remember, there's no difference between the two events so it doesnt matter what you pick.

However it was pointed out to me that if you specify a maximum size for your window, this methodology wont work. The actual window message you want to look out for is WM_SIZE (0x05). The wParam of this message gives you details about what's just happened to the window, whether it's been maximized, restored, etc. There is no event that matches this window message, so roll up your sleeves it's WndProc magic hour! [1]

There are a couple of other window messages that correspond to sizing, which get everyone all confused. WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED occur during the sizing of a control - usually in a response to a call to SetWindowPos. The most likely place for windows forms to use SetWindowsPos is when you're actually setting Width, Height, Size, Bounds, Location - this usually all funnels to one virtual method called SetBoundsCore (which I've mentioned how to debug before).

There is one window message that sneaks in between the WM_WINDOWPOSCHANGING (the I'm about to change size message) and the WM_WINDOWPOSCHANGED (the hey I've changed size message) for toplevel windows - this is WM_GETMINMAXINFO. For toplevel windows with a maximum or minimum size requirement, WM_GETMINMAXINFO is used to apply size restrictions. This is where the Form.MinimumSize and Form.MaximumSize are applied.

In my dealings with these window messages, pretty much these are the only ones you'll care about. Everything else in my experience (like WM_MOVE, etc) seems to be syntatic sugar.

[1] WndProc Magic hour:
     protected override void WndProc(ref Message m) {
            if (m.Msg == /*WM_SIZE*/ 0x0005) {
                this.Text = this.WindowState.ToString();
            }
            base.WndProc(ref m);
        }

Tim shows how to get glass in your client area using Windows Forms

jfoscoding — Wed, 19 Apr 2006 18:25:00 GMT

Here's how to do it. (Requires Windows Vista and some willingness to fiddle with how your app paints itself).

ToolStripManager.SaveSettings and UserControls

jfoscoding — Wed, 12 Apr 2006 20:44:00 GMT

Ingas asks a great question:

In windows form I have a ToolStripContainer inside a control (inherided from UserControl). I allso have a ToolStripContainer on the main form. I am trying to do ToolStripManager.LoadSettings() (with ToolStripManager.SaveSettings allready done earlier) - supplying the main form. The toolbars on the main form restore their positions, as well as the toolbars that have been moved to the main form by the user. But the toolbars inside the control does not. Is there (or will there be) a method that is fit for the user control?

You can use the same SaveSettings and LoadSettings – the problem you’re most likely running into is that SaveSettings and LoadSettings require you to have unique names for all your ToolStripContainers and ToolStrips. If you add a UserControl to your project and drag and drop a ToolStripContainer, it’s very likely that it is named “ToolStripContainer1” – this may clash with the “ToolStripContainer1” that is on your form.

If you look at what the settings scribbles out (mine was in a hidden directory C:\Documents and Settings\USERNAME\Local Settings\Application Data\Microsoft\WindowsApplication50.vsho_Url_cuxemhukaqqokqln4jqkqtjcvnmlj1iq\1.0.0.0\user.config) [1] you’ll see that the ToolStripManager saves out information based on the names of the items.

If there are multiple ToolStrips or ToolStripPanels of the same name, the ToolStripManager will just use the first control it finds of the same name. The fix is to ensure you have unique names for *everything* on your form.

Here’s how I set up settings that work with a UserControl:

Create a new form.
- Drag & Drop a ToolStrip
- Open the smart tag, choose Insert Standard Items
- Open the smart tag, choose Embed in ToolStripContainer
- Open the smart tag for the ToolStripContainer, choose Dock fill in container
Create a new user control in the project
- Drag & Drop a ToolStrip
- Click the “new item glinker” to add a few stock images
- Open the smart tag, choose Embed in ToolStripContainer
- Open the smart tag for the ToolStripContainer, choose Dock fill in container
Important step - rename UserControl1's controls to be unique!
- Rename ToolStrip1 to UserControlToolStrip1
- Rename ToolStripContainer to UserControlToolStripContainer1
Hook up settings
- Go to the form and add handlers for the Load and FormClosing events.
- Write this code

private void Form1_Load(object sender, EventArgs e) {

ToolStripManager.LoadSettings(this);

}

private void Form1_FormClosing(object sender, FormClosingEventArgs e) {

ToolStripManager.SaveSettings(this);

}

That’s great but I followed your advice and my ToolStrip disappeared!

How to rename your controls:

If you rename your toolstrip or your toolstrip panel and you run the application again, you may notice that your toolstrip disappears. If there is no matching container for your toolstrip, the ToolStripManager assumes that the panel it was in has disappeared and therefore it should not add it.

The easiest way to write a “Reset” for your form is to save the settings before calling load…

private void Form1_Load(object sender, EventArgs e) {

ToolStripManager.SaveSettings(this,"reset");

ToolStripManager.LoadSettings(this);

}

public void Reset() {

ToolStripManager.LoadSettings(this, "reset");

}

More information

Ragha posted some more information on settings a while back - ToolStripManager uses the same settings APIs to store.
There's also information in the ToolStrip FAQ.

[1] Showing the config file for purposes of illustration. One should not directly parse the settings file from disk as there are multiple storage mechanisms for settings.

Windows Forms documentation team is blogging

jfoscoding — Tue, 21 Mar 2006 23:12:00 GMT

Welcome the folks behind the reams and reams of Windows Forms documentation to the world of blogging! In their own words:

We're the Windows Forms User Education team at Microsoft. Here you can find updates on documentation related to Windows Forms, ClickOnce, and Smart Client programming months before the documentation is released in new doc builds. Check out what we have to offer, test it out, and give us your feedback if you see something amiss! We want YOUR help in making our documentation set the best it can be.

NOTE: The updates posted to this site are static. They will not be updated as they become obsolete; we're publishing them merely to give you a "sneak peek" at what we've written that has yet to be released. The latest publicly available build of the documentation should be considered the only official documentation. Any docs provided here are provided as-is, with no express or implied warranty.

WM_GETCONTROLNAME

jfoscoding — Fri, 10 Mar 2006 08:12:00 GMT

Folks quite often ask how to get information about controls from outside the process. In addition to active accessibility (the recommended solution for testing windows forms applications) there's also a handy window message which Control supports called WM_GETCONTROLNAME. Calling SendMessage with WM_GETCONTROLNAME returns the Control.Name property. Brian McMaster has talked about this special message here, and how to use it with VisualTest.

The one giant caveat about using this method is that from outside the process, you need to use shared memory to make it work as the remarks for SendMessage point out:

The system only does marshalling for system messages (those in the range 0 to (WM_USER-1)). To send other messages (those >= WM_USER) to another process, you must do custom marshalling.

Ben's Managed Spy sample has sample code for creating memory mapped files, which of course has even richer information returned back for Windows Forms 2.0 forms.

ProfessionalColorTable - what does what?

jfoscoding — Wed, 08 Mar 2006 09:43:00 GMT

If you've read the ToolStrip FAQ, you may already be aware that you can replace the colors of the ToolStrip by passing in a new ProfessionalColorTable to the constructor of the ToolStripProfessionalRenderer.

How can you tell what color does what?

Create a form, then add in a property grid and set the SelectedObject to the ProfessionalColorTable. You should be able to see all the colors and descriptions of the colors.

PropertyGrid pg = new PropertyGrid();

pg.SelectedObject = new ProfessionalColorTable();

pg.Dock = DockStyle.Fill;

this.Controls.Add(pg);

If you want the same colors as VS, that's ground we've already covered.