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?

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.

Grabbing .dmp files from crash dialogs

jfoscoding — Thu, 30 Nov 2006 20:35:00 GMT

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.

I'm a sloucher.

jfoscoding — Tue, 28 Nov 2006 21:35:00 GMT

And now I can be ok with it. Anyone got a protractor so I can measure off 135 degrees?

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!

Sometimes I F5 when I meant to just compile.

jfoscoding — Mon, 09 Oct 2006 20:13:00 GMT

Usually such a mistake is followed by a "noooooooooooooooooooooooooooooooooooo!" and quiet resignation to wait for my app to build and get to the point under the debugger where I can stop it.

So here's a super-handy tip for larger projects I learned last week: You can cancel a build using CTRL+Break.

I know you've all been wondering...

jfoscoding — Thu, 28 Sep 2006 06:30:00 GMT

The answer is: October 6th.

Learning WPF

jfoscoding — Fri, 22 Sep 2006 03:24:00 GMT

I’ve put together a series of articles on WPF, from a Windows Forms developer perspective. This started out as a simple document entitled “So you know Windows Forms and you wanna learn Avalon” way before there was as much content out there as there is now. I hope this twist in perspective is useful for folks.

Enjoy!

[Update: MHT wasn't working out as well as I wanted, so you can now also just download the whole thing.]

Playing around with WPF/GDI+ Resource interop

jfoscoding — Wed, 20 Sep 2006 07:49:00 GMT

WPF Resources

A while back, Jim posted a summary of the different types of resources in WPF. We know that from the 1.0-2.0 versions of the .Net Framework, there were basically two ways to load an image from a resource: through .resx files and by directly adding them to the solution and changing the Build Action to “Embedded Resource”.

If you’ve ever tried to load a Bitmap in Windows Forms using the new Bitmap(typeof(MyType), “sunset.jpg”) constructor, you’ll appreciate that they wanted to do something more friendly for markup in WPF.

In particular, its:

To make this work, you need to add an image to your project, and make sure (in the property grid) that the Build Action is set to Resource.

WPF/GDI+ Resource interop

The other day I ran into a situation where I wanted to potentially display an image in either WPF or in GDI/GDI+. I wanted to have one way to specify the image, but the flexibility to use either technology to render the image.

The solution? Use WPF’s new URI syntax and the helper methods on WPF’s application class to load the resource into a stream, then use the System.Drawing.Bitmap constructor that takes a stream.

I’ve put together a sample that shows how to load an GDI+ image from a WPF resource.

I made several discoveries while writing this sample:

Michael Weinhardt has recently released a new article on resources. You should check out his new msdn magazine article on how pack uri’s work.

There’s kinda-sorta an alternate HBitmap solution. If you’re starting with an HBitmap, you can use WPF’s System.Windows.Interop.Imaging methods such as CreateBitmapSourceFromHBitmap and friends. Unfortunately I couldn’t find a way to take a WPF image and scribble to an HBitmap.

Using the Loaded event for custom code is much more sane. If you throw an exception in the constructor of the Window, you’re doing it in the XAML parser context – so you’ll get a XamlParseException, with your actual exception in the InnerException.

The sample

Lets walk through a sample interop case. If you just want to see the code – skip to step 8.

Step 0: Install the latest version of Cider

Step 1: Create new WPF Windows application

Step 2: Right click on the project, surf to your sample images in My Pictures and add Sunset.jpg to the project

Step 3: Double check the properties window to ensure that the “Build Action” property for Sunset.jpg is set to “Resource”.

Step 4: Edit XAML.

<Window x:Class="WindowsApplication69.Window1"

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

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

Title="WindowsApplication69" Height="300" Width="300"

<Grid>

</Grid>

</Window>

Step 5: Click back on the designer and verify that the image loads (this is a new feature in the latest CTP, enjoy!)

Step 6: Add the references we’re going to need to do some interop. Expand the references section in the solution explorer and add a reference to:

System.Windows.Forms

System.Drawing

WindowsFormsIntegration

(look Program Files\Reference Assemblies\Microsoft\Framework\v3.0\ for the last one – it helps us use Windows Forms from WPF markup).

Step 7: (You’re still with me? Great!) Go back to XAML and add in the windows forms namespace to the window tag:

xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"

And then go ahead and add a WindowsFormsHost with a picture box in it.

<wf:PictureBox x:Name="pictureBox"/>

</WindowsFormsHost>

So that your final code looks like so:

<Window x:Class="WindowsApplication69.Window1"

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

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

xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"

Title="WindowsApplication69" Height="300" Width="300"

<Grid>

<wf:PictureBox x:Name="pictureBox"/>

</WindowsFormsHost>

</Grid>

</Window>

Step 8: Write code! Flip to Window1.xaml.cs.

public partial class Window1 : System.Windows.Window {

public Window1() {

InitializeComponent();

this.Loaded += new RoutedEventHandler(Window1_Loaded);

}

void Window1_Loaded(object sender, RoutedEventArgs e) {

// build up a relative path to the image.

System.Uri imageLocation = new

System.Uri("/WindowsApplication69;component/Sunset.jpg",

System.UriKind.Relative);

pictureBox.Image = GetBitmap(imageLocation);

}

private System.Drawing.Bitmap GetBitmap(Uri uri) {

// Use the helper methods on WPF's application

// class to create an image.

using (Stream resourceStream = Application.GetResourceStream(uri).Stream) {

return new System.Drawing.Bitmap(resourceStream);

}

Some of these pages are no longer intentionally left blank.

jfoscoding — Wed, 13 Sep 2006 18:15:00 GMT

One thing we neglected to mention in the release notes is that you can now load up roots other than Window and Grid in the August CTP. The list I believe is anything deriving from Panel, Page, UserControl and ContentControl.

So if you have the latest installed - try replacing your window1.xaml with this:

<Button x:Class="WindowsApplication65.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Height="75" Width="100">
Hello world!
</Button>

If you want to drag and drop into it, replace the contents with a Grid. For button you may have to size the grid in code, as the button layout sizes grid to zero.

More interestingly, you can now design user controls.

Have fun!