August 2010 - Posts
In one of my previous posts I’ve published the code for a Live Writer plug-in that allows you to easily add to your post share buttons for common technological sharing sites, like:
Since I figured this plug-in can be useful to other people as well I’ve published it on the Microsoft Live Gallery, a gallery for Live Writer plug-ins and more.
You can download the plug-in here and find details and source here.
That’s it for now,
Arik Poznanski.
Back in this post I showed you how you can have a look at the original source code of .NET, including original comments and variable names.
In this post we’ll see a few interesting things about WPF’s Dispatcher class.
But first some background on the subject.
WPF Thread Affinity
Almost every WPF element has thread affinity. This means that access to such an element should be made only from the thread that created the element.
In order to do so, every element that requires thread affinity is derived, eventually, from DispatcherObject class. This class provides a property named Dispatcher that returns the Dispatcher object associated with the WPF element.
The Dispatcher class
The Dispatcher class is used to perform work on his attached thread. It has a queue of work items and it is in charge of executing the work items on the dispatcher thread.
So, when you want to change a property of a WPF element from a thread different of the one who created the element, you should use the element’s Dispatcher property to dispatch the operation to the correct thread. This is done using the BeginInvoke method that accepts a method to be invoked.
Where is the Dispatcher of the thread saved?
Every thread should have their dispatcher object, so you would think they will save the dispatcher on the Thread Local Storage (TLS).
It turns out they store a static list of all available dispatcher objects.
Of course, this list is synchronized using a private global static object (this is a common best practice when locking object).
Whenever the dispatcher of an object is needed, they go over the list, comparing the dispatcher’s Thread property with the current thread, until they find the correct dispatcher object for this thread.
The reason, as they note in the comments is that managed TLS is rather expensive.
Above this list they add the following optimization: before going over the dispatchers list they check if the last given dispatcher is suitable, so only a thread context switch will derive a new list search.
Although strange, this usually isn’t such a problem because most application will only have one thread that creates UI elements, hence only one Dispatcher in the list.
That’s it for now,
Arik Poznanski
The Windows Ribbon for WinForms is a managed wrapper around Windows Ribbon Framework, a free ribbon control that Microsoft provides in Windows 7 and Vista.
More details on this project can be found in the project site: windowsribbon.codeplex.com .
I’ve just released yet another update to the project.
This release adds support for compiling the project on 64bit machines.
If you use a 32bit machine, you are safe with your current version.
The main change is how I compile the samples applications. Some of the tools I need for compilations resides in directories which are different between 32bit and 64bit of windows.
That's it for now,
Arik Poznanski.
About a month ago, CodePlex have upgraded their TFS servers to to TFS 2010.
While this transition was supposed to be invisible to users who connect using the SVN interface, it wasn’t.
The Problem
This is what I got while trying to update a project which resides on CodePlex, using AnkhSVN plug-in.
Or in a search-engine friendly way:
SharpSvn.SvnException: Repository UUID 'XXX' doesn't match expected UUID 'YYY'
at SharpSvn.SvnClientArgs.HandleResult(SvnClientContext client, SvnException error, Object targets)
at SharpSvn.SvnClientArgs.HandleResult(SvnClientContext client, svn_error_t* error, Object targets)
at SharpSvn.SvnClient.Switch(String path, SvnUriTarget target, SvnSwitchArgs args, SvnUpdateResult& result)
at SharpSvn.SvnClient.Switch(String path, SvnUriTarget target, SvnSwitchArgs args)
at Ankh.Commands.SwitchItemCommand.<>c__DisplayClass7.<OnExecute>b__0(Object sender, ProgressWorkerArgs a)
at Ankh.ProgressRunnerService.ProgressRunner.Run(Object arg)
The Solution
We will use Visual Studio excellent “Find and Replace” in files.
Just follow these steps:
- BACKUP your local project folder
- Open Visual Studio
- Select Edit –> Find and Replace –> Replace in Files (or press Ctrl + Shift + h)
- In the “Find what” field write the expected UUID (you can get it from the previous error message)
- In the “Replace with” field write the new UUID
- In the “Look in” field write the name of the local folder where your project resides
- Expand the “Find options” and write the word “entries” in the field named “Look at these file types”
- Click “Replace All”
Following is an image that summarize these changes for my project:
When you get the following warnings, just select Overwrite (Alt + o).
And we’re done. Your project is officially fixed.
That’s it for now,
Arik Poznanski.
The Windows Ribbon for WinForms is a managed wrapper around Windows Ribbon Framework, a free ribbon control that Microsoft provides in Windows 7 and Vista.
More details on this project can be found in the project site: windowsribbon.codeplex.com .
Anyway, I’ve just released a new update to the project.
This release includes bug fixes related to all the gallery controls: DropDownGallery, SplitButtonGallery, InRibbonGallery and ComboBox.
So, if you had any issues with these controls, make sure you put your hands on this version.
That’s it for now,
Arik Poznanski.