jfo's coding

Blog has moved ...

jfoscoding — Wed, 09 Mar 2011 23:52:51 GMT

I am back blogging at http://jfoscoding.blogspot.com/! See you over there!

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?