jfo's coding

Mark shows off some of the new and exciting features in Cider Beta 2, including:

• DataSources window now works in Silverlight (as well as WPF) - you can now drag and drop from this window to your design surface to automatically hook up to data.
• Property Inspector window gets a facelift  --  now lets you sort by property source (e.g. see all the locally set versus inherited properties grouped together)
• {d:DataContext} markup extension lets you set design time data across Cider and Blend.
• UserControls can now use resources from App.xaml
• Designer now loads with broken controls -- a red x shows you the control that could not load, and a gold bar shows you the exact exception.  Previously you would have only gotten a "Problem Loading" screen.

We would love to get your feedback on these new features! 

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!

One of my favorite books of all time is The Pragmatic Programmer.  A piece of advice I've always taken to heart is to take the time to make tools that will make you more productive. 

Today's tool I can share with you - I didn't want to flip back and forth between the repro steps in my bug reporting program and the program I was trying to fix. 

So I created a TopMost window that will always be there so I can see what the next step is. 

• Open Visual Studio 2008 or 2005, create a new Windows Forms application.
• Select the Form in the designer
• Open the Property Grid and find the TopMost property.  Set TopMost=true.
• Drag and drop a RichTextBox from the toolbox
• Select "Dock in parent container" from the designer action panel, or go to the property grid and choose Dock=Fill
• F5 to run the application
• Paste in repro steps from the bug! 
• (Tip - if the steps are in HTML, you may want to paste into word first, then the rich text box to get better formatting).

 And voila!

Quick and simple repro-step viewer that stays on top of all applications.

I recently showed how to use the "Define a Dependency Property" snippet in VS to save time/frustration creating a new property on your control.  I often need a property changed event as well, and it's a bit of a pain to go back and add it.  I just figured out how to add/update snippets and thought I'd show you how to create a snippet with a property changed event:

        public int MyProperty {

            get { return (int)GetValue(MyPropertyProperty); }

            set { SetValue(MyPropertyProperty, value); }

        }

        // Using a DependencyProperty as the backing store for MyProperty.  This enables animation, styling, binding, etc...

        public static readonly DependencyProperty MyPropertyProperty =

            DependencyProperty.Register("MyProperty", typeof(int), typeof(Window1), new UIPropertyMetadata(0, OnMyPropertyChanged));

        private static void OnMyPropertyChanged(DependencyObject dobj, DependencyPropertyChangedEventArgs e) {

            Window1 owner = dobj as Window1;

            if (owner != null) {

                // todo: execute property changed code.

            }

        }

Save this snippet to your disk as somefile.snippet (view source)
In VS 2008, open Tools > Code Snippets Manager
Choose the language (this is a C# snippet)
Choose import...
Find the .snippet file, import it, and voila!

If you want to make a property that can be styled from XAML - you need to create a dependency property on your control.  This can be a tricky syntax, but fortunately the C#/VB editor have "snippets" that allow you to really quickly create one.

Let’s assume we’re creating a BorderVisibility property on a UserControl.  It defaults to Visibility.Hidden.

Right click on the code editor.
Choose “Insert Snippet ...”
Choose NetFX30>Define a Dependency Property

Tab through and replace the fields in green. 

Replace the following:

·         int with our return type: Visibility

·         ownerclass with the class that defines the property, e.g. UserControl1

·         0 with the default value for the property Visibility.Hidden

Here's the quick way to create a custom control in Cider. 

• Right click on project in Solution Explorer
• Choose “Add > New Item”
• Choose “Custom Control (WPF)”
• Two files will be generated – CustomControl1.cs and Themes\Generic.xaml

In the Themes\Generic.xaml you can edit the default template for the control.

<Style TargetType="{x:Type local:CustomControl1}">

        <Setter Property="Background"

                Value="Blue"></Setter>

        <Setter Property="BorderThickness"

                Value="1" />

        <Setter Property="Template">

            <Setter.Value>

                <ControlTemplate TargetType="{x:Type local:CustomControl1}">

                    <Border Background="{TemplateBinding Background}"

                            BorderBrush="{TemplateBinding BorderBrush}"

                            BorderThickness="{TemplateBinding BorderThickness}">

                    </Border>

                    <ControlTemplate.Triggers>

                        <Trigger Property="IsMouseOver" Value="True">

                            <Setter Property="BorderBrush" Value="Black"/>

                        </Trigger>

                    </ControlTemplate.Triggers>

                </ControlTemplate>

            </Setter.Value>

        </Setter>

    </Style>

Note that using a UserControl may be a better experience -- and definately if you can retemplate an existing WPF control that may give you a bit better performance (as it avoids loading and parsing a separate BAML stream). 

If you’re an old windows forms or GDI/Win32 person, you may be tempted to override OnRender for more complex UIs.   

A long long time ago I wrote how to create a custom control in Windows Forms.  I showed the technique for calling Invalidate() to call OnPaint again if MouseIsOver changed.

This technique turns out to be a bad idea for WPF and Silverlight.  To understand why it’s good to know how WPF is different from Windows Forms/GDI/GDI+.  Wikipedia does a great job of explaining the under-the-hood details of the compositing system.  When you write code in OnRender, you're essentially adding to the list of geometries that WPF will later use to send instructions to the video card.    When you're overriding OnPaint and using GDI/GDI+, you're sending drawing instructions to the card.

This effectively means the rendering engine in WPF is tied to the layout engine - in fact Arrange calls Render.  This was not the case in windows forms - the layout code was separate from the painting code (PerformLayout() would only call OnPaint if you called Invalidate() or set ResizeRedraw, and even then it was windows that would respond with the WM_PAINT message once everything else was processed).

I've scribbled atop the MSDN diagram to add a way of thinking about it...

 

Doctored diagram from MSDN...

Although the DrawingContext draw methods appear similar to the draw methods of the System.Drawing.Graphics type, they function very differently: DrawingContext is used with a retained mode graphics system, while the System.Drawing.Graphics type is used with an immediate mode graphics system. When you use a DrawingContext object's draw commands, you are actually storing a set of rendering instructions (although the exact storage mechanism depends on the type of object that supplies the DrawingContext) that will later be used by the graphics system; you are not drawing to the screen in real-time. For more information about how the Windows Presentation Foundation (WPF) graphics system works, see the Visual Layer Overview.   - (MSDN Fine Print)

When is using OnRender ok?

It is ok to use OnRender for things that won’t change, but what you render changes on MouseOver or SizeChanged, you’ll may be causing a layout perf problem for your app.

The way to avoid the OnRender tax is to predefine your UI in a template, then for the bits that change, use triggers within the template to change it. 

Next up: how to create a custom control in WPF using Cider.

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?

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"/> <!-- L, T, R, B -->

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

margin:20px 30px 40px 10px;

What is the difference between ActualSize, RenderSize, LayoutSlot?

There are quite a few properties in WPF and Silverlight for layout, and it is confusing.  It helps me to think of them in two separate categories – layout input properties (control layout), and layout output properties (set after the layout occurs)

Layout input properties 

·         Width/Height – specify the width/height of a control as a double.  For autosize in XAML say “auto”, for autosize in C#/VB say double.NaN.

·         MinWidth/MinHeight – specify the minimum size of a control.

·         MaxWidth/MaxHeight – specify the maximum size of a control.

·         HorizontalAlignment/VerticalAlignment –  the combination of these two properties specify the positioning within the parent (e.g. TopLeft, MiddleCenter,Stretch)

·         Margin – specifies the exterior spacing between the element and adjacent elements. (e.g. the distance between elements in a stack panel can be configured by margin).

·         Padding – specifies the interior spacing within the current element (e.g. the space from the top of the text box to the top of the character within the text box).

·         Panel specific layout inputs – additionally each layout panel may have attached properties that control  layout.

 Some examples include:

·         Grid – Grid.Row, Grid.Column, Grid.RowSpan, Grid.ColumnSpan

·         Canvas – Canvas.Top, Canvas.Bottom, Canvas.Left, Canvas.Right

·         DockPanel – DockPanel.Dock

Layout output properties

·         RenderSize- Technically, the output of the call to Arrange – think of it as “ArrangeSize”.  Its purpose is to tell you how big to draw a background.  If elements have a funky implementation of ArrangeOverride this property can return unexpected results.

·         ActualHeight/ActualWidth -  same as RenderSize.  The reason these exist is so you can databind to them.

·         LayoutInformation.LayoutSlot – this is the area in which an element can layout.  So for example if you’re in a grid, this would be the element’s current grid cell.

·         LayoutInformation.GetLayoutClip - clipping is used to “cut off” elements that extend past areas they don’t belong.  E.g. within a grid if a button is larger than the current cell and it has a column span set to 1, the grid will clip it to be the size of the current cell. 

Side note about clipping: If you are writing a custom layout it is interesting to note that the protected virtual GetLayoutClip() on FrameworkElement is what controls this – and it usually kicks in if the size in arrange is larger than the size in measure.  If you’re experiencing cut off buttons in your custom layout try returning null from GetLayoutClip() and see if that is your issue.

Common layout input properties in practice

ActualSize, depending on perspective may vary.

All of these output properties are relative to the element’s own coordinate system – if you want to figure it out relative to anything else you need to apply the transform from that object to the other object. 

Example: Button in a grid that scales everything by 2x. 

When you ask a 100px button it will say it's 100px wide, but it will render as 200px on the screen.

<Window x:Class="WpfApplication100.Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="Window1" Height="353" Width="398">

    <Grid>

        <Grid.RenderTransform>

            <ScaleTransform ScaleX="2"></ScaleTransform>

        </Grid.RenderTransform>

        <Button Name="button1"  Width="100" Height="75"

                HorizontalAlignment="Left"

                Margin="10,10,0,0"

                VerticalAlignment="Top"

                Click="Button_Click">Hi</Button>

    </Grid>

</Window>

Kinda like the observer principle in physics, the button itself has no idea that eventually its size will double.  It’s as if when you apply the render transform to the grid, you’re looking at the grid through a 2x magnifying glass. 

To get the "actual" actual width we need to transform the coordinate system into the Window’s coord system.  (Reality is all relative?)

               private void Button_Click(object sender, RoutedEventArgs e) {

            // get a magical formula that transforms button coords to window coords

            Transform button1ToWindowTransform = button1.TransformToAncestor(this) as Transform;

            // create a local coordinate rect.  if you don't pass in a point it's x=0, y=0

            Rect button1LocalCoordRect = new Rect(button1.RenderSize);

            Rect button1InWindowCoords = button1ToWindowTransform.TransformBounds(button1LocalCoordRect);

            MessageBox.Show(

                "Button1 thinks ActualWidth is: " + button1.ActualWidth + "\r\n" +

                "Button1 in window coords: " + button1InWindowCoords.ToString());

        }

In January, I'll be hanging up my keyboard for a while as I move to Australia.  I have really enjoyed my work at Microsoft; particularly with my team, which is filled with smart, talented folk who really care about doing the right thing. 

This will be my last post to blogs.msdn.com.  If you want to keep up with me, my new blog address will be http://jfoscoding.blogspot.com (Feed). 

You may want to check out my new years resolutions and the advice I'd give myself if I were starting over.

Thanks for reading - and wish me luck! =)

I've been heads down working on a project lately, and I've let a few questions build up.  My apologies for this, here's what I have (if it's still useful):

Updates from Everen on fixing the disabled drawing for the ever-popular SplitButton sample.
I've just wanted to thank you for the SplitButton code. Only glitch was that it wasn't rendering correctly when it was Disabled so i've added a check at the start of the OnPaint function to set the _state to PushButtonState.Disabled. Also added checks at the arrow and text rendering lines to render in Control.GrayText color.

Question on Control.Invoke
I'm surfing a treeview in a worker thread and I want to know if it's better to use Control.Invoke for this situation?
If you're not changing state, you might "get away" with this, but Invoke would ensure robustness as the treeview wont change out from underneath you.  The rule of thumb is touch the UI stuff only on the UI thread.  If you can use 2.0 try to keep CheckForIllegalCrossThreadCalls turned on.

Also, do you know if the "TreeNode.Tag" member (or any ".Tag" member of any control for that matter) needs to be invoked on the creating thread as well? Since this property really just stores raw programmer data I'm not sure if it's really necessary.

The "Tag" property is just an object.  But how you get a hold of the TreeNode on the secondary thread may be problematic (see the first response).  I would recommend keeping your data separate from your UI - use a hashtable or dictionary that both threads can look at - and take either locks as appropriate (if they're both using the same list) or use a BackgroundWorker style ReportProgress event:  the background thread presents a list which the UI thread copies and applies.

Question on ToolStripSettings
I was just wondering if there is anyway to save the Toolstrip to a non-default settings provider?
Unfortunately, this was an omission in the design.  You'd have to redo the settings persistence yourself.

Question on UnhandledExceptions
What exactly is an unhandled exception? Is this not a Unhadled Exception? if this is then why my ThreadException handler is not getting invoked?

try
{
   throw Exception();
}
//No catch block
finally
{

}

An Unhandled exception is when there is no catch block in the callstack.  If you're using the System.Windows.Forms.Application.ThreadException event to trap unhandled exceptions, you should know that the "catch" block under the covers only works when the message pump has already been started.  So if you throw from main before Application.Run or in the constructor while creating the argument you're passing into Application.Run or throw from a background thread, the ThreadException dialog might not be there for you.  Here's an example:

using System;
using System.Windows.Forms;

namespace Test {

   public class Form1 : Form {

       public Form1() {
         // This object isn't run under the message loop yet!  Application.Run hasn't been called! 
         try  {
            throw new Exception();
          }
          //No catch block
          finally {
          }
       }

       [STAThread]
       public static void Main() {
          // how it's typically written
          Application.Run(new Form1());

         // another way of writing the same code is:

         // Form1 f = new Form1();
         // Application.Run(f);

  
       }
   }
}

If you hook onto a few more things, you can get a more systematic approach to catching errors outside the message loop.

Happy Holidays!
JFo

I've been going through some older stuff, and I found a few "unpublished" works, which I'm posting for you as-is, un-edited, in all it's glory. 

The Painting Stages of the ToolStrip Renderer
Discusses the ordering of calls to the layers of the toolstrip renderer so you know what to override if you want to make a custom renderer.

Building a TabStrip from a ToolStrip (sample)
Discusses how to tweak the layout and painting of your toolstrip in very advanced ways to make a tab control.  Also discusses how to add some designer features.

Using TableLayoutPanel Walkthrough
Ooops! Guess what I forgot to add to the password dialog box... oh well, at least you'll see how to fiddle with columns and rows.
 

If you're a company wanting to get access to the data from the crash dialog, this article isn't for you.  But this is. 

Also, I am not an expert in this topic.

Now that that is off my chest, and we've all had fair warning, here's my scenario:  I've done something in an application that's caused it to crash and I get the "SomeProgram has encountered a problem and needs to close.  We are sorry for this inconvenience."  If you click on the "What data does this error report contain?" link, you'll notice it's also created a crash dump of the process. 

A couple of times I've wanted to look at the dump file that's sent to the Online Crash Analysis to see if it was my code on the stack.  Maybe it's a hard-to-repro thing, or maybe it doesn't repro under the debugger, yada yada.

Frustratingly, it's nearly impossible to get at that .dmp file.  If you happen to find it, you can't copy it aside.  And if you look for it after dismissing the dialog, the .dmp file has been deleted from the machine.

Or so I thought.  Here's the trick that worked for me on Windows XP Professional: use the backup utility to back up the .dmp file, then open it in Visual Studio or Windbg.  (I welcome anyone else's suggestions for a less painful process)

Creating an app that shows the dialog
(you can skip this step if you already have a crashy app).

• Create a new Windows Forms Application in Visual Studio 2005
• In Program.cs, add the following line before Application.Run
          Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
• Add a button to the form in the designer, double click on it and add the following code:
          private void button1_Click(object sender, EventArgs e) {
              throw new Exception("crash!");
          }
• Control + F5 (run without debugging) your new crash-tastic application

When you click the button you should now see the famous dialog.  DON'T close it or you'll lose the .dmp!

Finding the .dmp file

It should be in your temp folder.  Here's how I find it quickly:

• Start up a windows explorer (Windows+E) and put %TEMP% in your address bar to navigate to your temp dir
• View->Details to get the timestamps of all the files in your temp directory
• Click on the DateModified column to sort by date
• Look for a .dmp file that would be close to when you thought you crashed the app

Verify you can't copy the file..

• Try to copy/paste the .dmp file in Windows Explorer.

Now you see what I mean. (Cannot copy A8E2728: It is being used by another person or program.)  If you wait for the crash dialog to go away, the .dmp file will be removed from your machine.  So we have to take action now.

Open up the Backup utility

• Start->All Programs->Accessories->System Tools->Backup
• If you get the "Welcome to the Backup or Restore Wizard", swap to "Advanced Mode"
• Once you're in "Advanced Mode", click on the "Backup" tab.

Back up the .dmp file (you'll have to back up the entire temp dir)

• Navigate to the C:\Documents and Settings\JFo\Local Settings\Temp folder on the left hand tree.
• Click on the checkbox for the temp folder in the left hand tree
• In the right hand list, uncheck all the subfolders (e.g (C:\Documents and Settings\JFo\Local Settings\Temp\tempdir\))
• Don't worry if there is no checkmark next to the .dmp file itself - it seems to work on folders specifically.
• Click the "Browse..." button at the bottom of the dialog to pick the .bkf file to back up to (e.g. c:\BackupDumpFile.bkf)
• Click the "Start Backup" button
• In the "Backup Job Information" dialog, click "Start Backup"

Restoring the .dmp file from backup

• In the backup utility, click the "Restore and Manage Media" option
• Expand File in the left hand tree and navigate to BackupDumpFile.bkf
• Expand "c:", "Documents and Settings", etc... until you get to the Temp folder.
• When you've expanded the Temp folder, look for your .dmp file (if you click the modified column it will likely sort near the top)
• Check the .dmp file on the right hand side
• In the "Restore Files To" combo box, swap "Original location" to "Alternate location"
• Click the "Browse..." button to pick a different folder or type in a new folder, e.g. "C:\tempbackup"
• STOP!  Double check the settings to make sure you're restoring to the right spot and you have a warm and fuzzy feeling!
• Click the "Start Restore"
• Accept "Confirm Restore" dialog (if you're still feeling warm and fuzzy)

Look for the restored .dmp file on your disk:

• Mine was restored to C:\tempbackup\Documents and Settings\Jessica\Local Settings\Temp
• Open up windows explorer to find the file
• If you have Visual Studio on your machine, double click it.  Otherwise open it up in Windbg (link below)
• Hit F5 to run the dump file.

You should now see what state the program was in when it crashed - check the registers, get the call stack etc.

If you want to look at symbols, I'd recommend reading this article for how to set up the symbol server. You may also want to use strike to get a better picture of the CLR stack. In that case you may find using Windbg and SOS better.

For more information on working with .dmp files consult MSDN.