jfo's coding

Random tip of the day: adding a shortcut to all desktops in Windows Vista Server 2008

jfoscoding — Thu, 19 Nov 2009 01:56:00 GMT

I've been puzzling how to do this for a little while, as I had some common shortcuts I wanted to add to the desktop for everyone on my team to use.

The way to do this in Windows XP has been to use the "All Users" account and add to the desktop folder. The process is the same for Windows Vista, but "All Users" has been renamed "Public" and the "Desktop" folder is hidden by default.

To create shortcuts for everyone either

Open Windows Explorer (Easiest way is Windows key + e)
Type "C:\Users\Public\Desktop" directly
Add shortcut to this folder

Or unhide all the folders and navigate there

Open Windows Explorer (Easiest way is Windows key + e)
Press Alt to show the menu
Open Tools->Folder options menu
Select View tab
For the Hidden Files and folders option check "show hidden files and folders"
Now navigate to c:\users\public\desktop, you'll actually see it but it's ghosted out (because it's a hidden folder).
Add shortcut to this folder

I'm sure there's a million other ways to do this -- but I hope this helps!

Beta2 is out -- What's new in Cider

jfoscoding — Mon, 26 Oct 2009 22:36:00 GMT

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!

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!

Creating a bug repro viewer in 5 minutes

jfoscoding — Thu, 01 Oct 2009 07:06:00 GMT

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.

Tip: creating your own snippets

jfoscoding — Tue, 08 Sep 2009 09:14:00 GMT

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.

}

If you have a spare few minutes, it is very easy to add this – you need to use the Code Snippet Manager.

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!

Tip: quickly create a dependency property

jfoscoding — Tue, 08 Sep 2009 09:11:00 GMT

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

Creating a custom control in Cider

jfoscoding — Tue, 08 Sep 2009 09:01:00 GMT

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.

<Setter Property="Background"

Value="Blue"></Setter>

<Setter Property="BorderThickness"

Value="1" />

<Setter.Value>

<Border Background="{TemplateBinding Background}"

BorderBrush="{TemplateBinding BorderBrush}"

BorderThickness="{TemplateBinding BorderThickness}">

</Border>

<ControlTemplate.Triggers>

</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).

OnRender is not as cheap as OnPaint

jfoscoding — Tue, 08 Sep 2009 08:56:00 GMT

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.

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;

Demystifying WPF/Silverlight layout properties

jfoscoding — Tue, 08 Sep 2009 02:31:00 GMT

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>

</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());

}

G'Day from Australia!

jfoscoding — Tue, 08 Sep 2009 02:13:00 GMT

...and I'm back. Well not back back in Redmond back, but back doing the things I love with great people, just at a great distance. I want to apologize for my hiatus from blogging. I have been busy at work on the next version of the Cider designer for Silverlight and WPF, and I have some new ideas for blog posts.

Goodbye Redmond

jfoscoding — Fri, 29 Dec 2006 21:38:00 GMT

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! =)

Customer question roundup

jfoscoding — Fri, 22 Dec 2006 19:16:00 GMT

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

Bloopers and Outtakes

jfoscoding — Thu, 21 Dec 2006 03:29:00 GMT

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.