When I just posted the source code of the Dependency Property Serialization sample, I realized it included a small piece of source code that might come in handy from time to time:
A very basic, but rather exact profiler. It uses QueryPerformanceCounter. Perhaps I shouldn’t even call this profiler, because a profiler typically keeps track of the parts of code it measures. So let’s call it a precise stopwatch. Well, anyways, here’s the code:
First off, my apologies for not posting the second part earlier. I have had a lot to do in the past Months…
Part II of the article will show how a SerializationSurrogate works and explore wheter we can use it for generic de-serialization of DependencyProperties. Also, in this article I provide full source code for both parts of the article.
UPDATE: A much better version of this article can now be found at the CodeProject: DependencyProperty Serialization for Business Objects
Alternatively, directly get the source code here: http://www.emphess.net/wp-content/uploads/2009/03/bpboserialization1.zip
Ok, I did it: I tried to do it the easy way — serialization! And I quickly ran into the following issue: Serializing DependencyObjects. There are a lot of sources saying “you can’t serialize dependency objects”, which is true, but you can get pretty close rather quickly and it might not be the worst decision.
In this article, we’ll explore if and how reflection magic can assist us in doing it anyway, how we can locate DependencyProperties via reflection and what pitfalls remain. Moreover, I’ll give an outlook why the most desireable solution (that almost suggests itself) fails.
Well, this is the first post after a very long pause, I am sorry but I had very little time…
Anyway, I stumbled over some strange bug this morning that turned out to be related to the GC. But let’s just step back a minute:
The application I currently work on is based on CompositeWPF . I added a very simple module to the application, a simple passive debugging module. I called it “InspectorModule”. The InspectorPresenter now listens for global modifications to the business object which is kept by the BusinessEntityManager:
Now, upon each modification of the business object, ReloadInspector shall be called. So, starting the application and triggering the event — nothing happened. The ReloadInspector method is not being called. Why?
After some debugging, it suddenly worked - the only problem being: I didn’t actually change anything!
To make a long story, I realized the CompositeWPF DelegateReferenceclass keeps a WeakReference to the object (the InspectorPresenter, in this case) when registering it via the EventAggregator as above.
Unfortunately, due to the simplicity of the InspectorPresenter, no instantiated object actually keeps a reference to the Presenter (apart from the WeakReference of the event which, by definition, does not prevent it from being finalized).
That’s why the object is being finalized and the event never fires. Actually, on the first call of the associated Publish() method, the Composite WPF-Internal EventBase.PruneAndReturnStrategies() will remove it from the list after it’s associated Action is supposedly null.
Debugging this was quite cumbersome, and the solution of striking simplicity: I simply continued to develop the “Inspector”, a little more than I originally planned, so the user can now select an object in the inspector. Now, I have a simple event like this:
This keeps a (strong) reference to the Presenter, and the GC does not kill my presenter anymore! The reason it worked when debugging, I guess, is that the debugger will keep the GC from finalizing objects under certain circumstances.
There are some very interesting posts I missed the last days. Since .NET 3.5 SP1 perfectly integrates WPF with DirectX, a number of cool effects can finally be applied:
http://www.codeproject.com/KB/WPF/WPFPixelShader.aspx
http://blogs.msdn.com/greg_schechter/archive/2008/05/12/introduction-to-writing-effects.aspx
Some of those effects were on Dax Pandhi’s wish list for WPF (http://blog.nukeation.com/post/My-wishlist-for-the-next-release-of-WPF.aspx) for quite some time.
More importantly, the integration of WPF and Direct3D might eliminate the need for a custom overlay control for the MenuKiller Control, which is a major performance hog (I currently use an overlay similar to this: http://blogs.msdn.com/pantal/archive/2007/07/31/managed-directx-interop-with-wpf-part-2.aspx).
This is just a draft on my upcoming article. I have asked a number of WPF Gurus to help me out on this…
In an effort to take user experience to the next level, designers have come up with ideas on how to solve old problems in a new way. In the last few months, the term “Differentiated User Experience” or simply “Differentiated UX” has come up to describe these efforts.
One of the beforementioned UI designers is Dax Pandhi, who published an article “Rethinking the Button” on his blog which introduced a new control he calls MenuKiller. This control is certainly more than a replacement for the Menu and ContextMenu, as it can be used in ways that are quite different. However, it turns out that changing the way things are typically done is indeed not so easy.
This article gives an overview of my implementation of the MenuKiller and presents a small sample application. It’s written in C# using .NET 3.5 and Visual Studio 2008. What is presented here is not a full-fledged control, since there are quite a number of open todos. Yet, I hope that this motivates the use of different controls and serves as a good starting point for other WPF control development.
A new Prism drop has just been released:
http://www.codeplex.com/prism/SourceControl/DownloadSourceCode.aspx?changeSetId=10933
The current prism drop comes with a neat documentation. Unfortunately, I won’t be able to check it out for the next few days…
The StockTraderRI now looks like this: 
.
Have you ever tried to call ICommand.CanExecute()? It actually works fine, but only if you are not as naive as I am… Simply calling it without the proper know-how might result in a NullReferenceException, so what you should read is how to implement ICommandSource. See
MSDN: How To: Implement ICommandSource
MSDN: Implement ICommandSource Sample.
Not a big thing, but since google didn’t show anything for “ICommand.CanExecute NullReferenceException”, it might help somebody I hope…
Today, I encountered two WPF related problems:
Every UIElement has an Opacity property, which will we be used when rendering the control. When rendering an object, 0.0 means the object is fully transparent, thereby invisible to the user, while 1.0 means it is fully opaque. Since controls can be composed so simply, it is desireable that child controls will use the opacity of their parents, so you don’t have to set it explicitly for each child.
So there is some kind of opacity stack, which will multiply opacities with each other when traversing down the tree upon rendering. Therefore, a 100% opaque button on a 10% opaque canvas will yield 10% opacity for the button (for an even longer description, see this MSDN entry).
However, it also seemed natural to me that it is well possible to specify an opacity of 2.0, so the child of a half-transparent object is rendered fully opaque (the same math applies). This is, however, not the case. While there are no warnings or exceptions (even the value is preserved), it will be clipped during the rendering process silently, therefore not allowing any UIElement to be more opaque than their parent.
For the MenuKiller Control, that is a catastrophe, since it changes the opacity of children all the time in order to convey the hierarchical concept better.
So, what I came up with is a helper-method that does the whole thing manually… Any thoughts on this one?
I really don’t understand why this is not allowed, since it would make some things a lot easier, at a very low risk of objects that are too opaque.
When testing the MenuKiller Control, I realized (not for the first time, but the first time it bugged me), that the XAML code I had did not work entirely correct.
The Button has a few triggers, including these:
The button has a trigger for the IsMouseOver property, so this should increase the opacity to 100% if hovering:
This works, but only as long the button is never clicked. If the button is clicked once, it will simply stay at its default 0.7 opacity. The only thing that still works is the animation for IsPressed.
(The red dot, by the way, is only a debugging tool, not a mistake)
I wondered how this could happen, trying to figure whether the button might behave like a ToggleButton for some reason. But it didn’t.
Instead, I realized that the trigger system, being based upon EnterActions and ExitActions, would have to preserve the controls’ state somehow. Several storyboards could easily cross each others paths, isn’t it? Interestingly, there is a property called HandoffBehaviour which I did not know until then. Unfortunately, the default value is already SnapshotAndReplace, while the only other option Compose was clearly not what I wanted.
As it turns out, the ExitAction, once applied, will stay on the control as long as the original enter condition is valid. Therefore, one simply has to remove the storyboard explicitly if another animation is supposed to be visible to the user. This yields the following XAML Code:
What it accomplished, in the end, is the newest incarnation of the MenuKiller, here in Debug draw-mode:
