digitalMoto.net

I learn things is by ripping them apart, putting them back together, and/or putting them together so I can rip them apart. I want to learn how MS leverages ServiceLocator, MEF, and the composition featers highlighted in Prism.

To this end, I have been playing with the Stock Trader Reference Implement from the Patterns and Practices team. I took all of the content from the 6 or 7 dlls and shoved it all into a single project. Just because… Moving the App.xaml file from the StockTraderRI project into my project sent things sideways. After I resolved all of the ‘other’ build issues (namespace, embedded resources, data inputs, etc), I found that I didn’t have a static Main entry point ala “does not contain a static ‘Main’ method suitable for an entry point” error.

Solution

Click on the App.xaml file.
Select Build Action
Set to ‘ApplicationDefinition’

That’s it.

Enjoy!

I have grown tired of looking up the named colors for my WPF apps.  So I wrote a Helper class to make my life a little easier. 

After playing around with this idea for a couple hours, I found a Dictionary<string,Color> is the easiest and most flexible way to reach my goal. 

Read more…

Freeze()

In our app, we are using converters to manage colors.  We have row color mappings.  We have column header color mappings.  We have error color mappings.   All of these colors are applied at a cell level in the XamDataGrid.  This requires a handful of new brushes at execution.  These colors never change.  They are static once they are assigned.

In my reading on WPF performance, I found a note about using Freeze() on brushes.  When you set the brush to frozen, WPF doesn’t bother to wire up the change handlers.  Fewer change handlers == faster app. 

The old code was creating a new brush for each and every request.

Read more…

Last week, my lead was working on a patch for an older version of our app.  We started brain-storming on how to fix a couple issued that we had already resolved in newer versions of the app.  (These patches are “normal” in our workflow.  We have different teams using different features within the app.  As a result not all teams/users are running the same version of the app.)

Work Items

One reoccurring problem with our app is cold start load time. It takes 8 – 10 seconds for the XamDataGrid to load AFTER the user has selected their runtime options. This is now our #1 complaint.

We had another issue with sorting within the grid.

Background

To take a step back, we are using attached properties to bind all of the fields, fixed fields, and manage our custom sorting.  For some unknown reason, the sorting wasn’t working.  Tracing lead us to an order of operations issue.  The sort was being called before the fields were bound.  To work around this, I wrote extra code in the behavior to sort after the fields had been loaded. 

Here’s what the XAML code used to look like.  

Read more…

In a side-by-side comparison, WPF will ALWAYS be slower to load than WinForms.  It’s a fact of life for the moment.  When using an Infragistics XamDataGrid, the start up lag is very noticeable.  This issue is one of our users biggest complaints.  “It takes too long to load” 

Yesterday, I learned that Infragistics uses a Just-In-Time model for loading their methods.  This adds to the delay when loading a XamDataGrid.  I also found code to pre-load the methods.  I added the method to my App.xaml.cs code.  The idea being to start the pre-load as quickly as possible.  When I launch my app 14,000+ methods can be preloaded. 

According to the discussion on the Infragistics forum, pre-loading can reduce load time up to 3 fold.  Your results may vary…

Below is the preload code (tweaked) with a link to the original source.  The code is from the sample project (XamDataGrid_PerformanceLoading.zip).  Download and extract it if you’d like to see the original version. 

Read more…

Yesterday, I ran into a problem where I was getting an exception on a reference to the built-in BooleanToVisibilityConverter when running my tests.  I don’t have the full error message any longer, but the message related to a StaticResource.

Weird.

To cut to the meat of the issue…

When you run a test, there is no visual tree.  If your code activates a view, then the test harness has to build the view.  If your xaml code contains references to resources not contained within the xaml itself, the xaml will try to wire up the resource without a visual true to reference.  In short, you’re gonna have problems. 

Read more…

• Marilyn Manson
• Men at Work
• Ministry
• Mr. Big
• Sixx: A.M.
• Tin Machine

And Memory…

Reminder to self:

When disconnecting a dependency property, don’t ‘set’ the value of the dependency property in code because the change handler never gets called. 

Bonus: 

Delete all of the dependency property code, keeping only the meaningful code from the handler. 

Assumptions:

• XamDataGrid
• Attached property used to capture the MouseDoubleClick event

private static void MouseDoubleClickHandler(object sender, MouseButtonEventArgs e)
{

  var sourceParent = VisualTreeHelper.GetParent((DependencyObject)e.OriginalSource);
  if (sourceParent is RepeatButton) // eject if double click in scrollbar
    return;

  ...

}

True codeplex gold! 

Once again, I ran into a binding problem.  I want a view to bind to a XamDatGrid contained inside the selected content pane inside of a XamDockManager.  I have a sample project working perfectly with this syntax:

  DataContext="{Binding ActivePane.Content.DataContext}"

When it was time to migrate the code over to my production app everything fell apart.  Eventually, I found a circular DataContext reference by using Snoop.  My detail view was bound to the same view model as the content pane housing the XamDataGrid.  So binding to Path=ActivePane.Content was the same as binding to Path=. which did nothing to get me to the active item in the view model.  Oops.

My final solution was to expose the ViewModel behind the View at the DockManagerViewModel level.  So now this XAML code works:

  DataContext="{Binding Path=ActiveViewModel}"

Snoop: the WPF Spy Utility  Learn it.  Know it.  Love it.

Here’s how I managed to get there. 

I merged 2 assemblies.  (Both contained xaml files.) 

My steps to get into this minor mess.

1. Dragged the files from the smaller assembly into the larger one. 
2. Renamed the larger assembly. 
3. Updated the project properties to match the new name/function of the assembly through the project properties screen.   
4. Ran the ‘Adjust Namespace’ tool in Resharper across the entire project. 
5. Build
6. BOOOOM!!!

The first error listed is:

Library project file cannot specify ApplicationDefinition element.

Does that sound familiar?

The problem is the ‘Build Action’ on the .xaml file properties.  When I moved the xaml files the build action was changed to “ApplicationDefinition”.  These settings fix it:

Build Action –> Page

Copy to Output Directory –> Do not copy

Custom Tool –> MSBuild:Compile

Go through all of your xaml files.  Make sure they are all using these settings. 

Worked for me. 

Reference:

Buried in this article is a pointer by Marco Zhou that helped me figure it out.   

With WPF apps, you can add a last-ditch exception handler.  As usual there are two ways to wire it up.  You can add it to the App.xaml

<Application
  …
  DispatcherUnhandledException="ApplicationDispatcherUnhandledException"
  >

or you can add it into the constructor App()

public App()
{
  DispatcherUnhandledException += AppDispatcherUnhandledException;
}

voidAppDispatcherUnhandledException(objectsender, DispatcherUnhandledExceptionEventArgs e)
{
  throw new System.NotImplementedException();
}

The purpose of this handler is to catch any unhandled exceptions from the main UI thread. Which also presents its limitations.  It works only on the UI thread.  That said, every time I hosed my app it was on the main UI thread. 

Silverlight apps don’t have this exact functionality.  In Silverlight, you handle the UnhandledException.  The “dispatcher” is left out of the mix.  It can be wired up in basically the same way as the WPF version.  My guess is that because Silverlight runs within the browser context, it never has control of the main UI thread.  IE/Firefox/Chrome are hosting the Silverlight app so handling exceptions is more limited in a contextual sense. 

I use the DispatcherHandlerException to handle fatal errors.  As the app closes, I can capture the exception details and save them as needed.  (E.G.: Log the error, send tech support email, etc.) Then I provide some information to the user so that the app doesn’t “just close” without any notice.  Apps that go blank tend to annoy my wife.  If my wife would be annoyed, I can safely assume someone else would be annoyed too.

If you can recover from the exception, you can mark the event as handled and keep going.

CYA early and often.

References:

WPF Version: DispatcherUnhandledException

Silverlight Version: Unhandled Exception

This is an continuation of the code I posted yesterday. 

I ended up reworking and extending my VisualTreeHelpers class after more research. 

With this version, I’ve tried to merge several ideas with a more fluent naming style.  First, I found that I needed to walk the VisualTree looking for (possibly) multiple instances of a given class. The new GetDescendantsByType<T>(DependencyObject parent) method supports that.  I disliked the GetAncestorByType<T>(DependencyObject descendant) logic, so I reworked it to suit my tastes.  And of course, I renamed things.  The influences remain, but the direct lineage is less obvious.   

Babble, babble…

Read more…

Continuing with the theme of standing on the shoulders of those who came before us…

Today, I need to find a control “somewhere” in the visual tree.  I found two different solutions to the issue.  One finds child controls.  The other finds ancestors.  Since I copped the code from other sites (link in the comments section for each method) I won’t promise that everything works to perfection.  I’ve used the FindVisualChildByName<T>() method in my code so my confidence is higher with that one.

Here’s the class I ended up with: 

Read more…