WPF Binding Culture

By default, WPF (as of version 4.0) will do all its bindings using en_us culture. The issue is reported to Microsoft, but is closed as by design. On that page, there are a few workarounds.

The simplest workaround is:


Another workaround is to specify the language of the xaml page by setting the Language property:



This will affect all bindings on that window.

The main drawbacks of this methods are that if the user has made changes to the local culture on his computer, this changes will not be taken care of. The solution to this is to make a completely custom Converter that does all the job.

Versatile WPF Boolean to Visibility Converter

The BooleanToVisibilityConverter that cames with WPF has some weak points because it cannot handle Visibility.Hidden or it cannot work in 'inverse' mode.

Suppose you have two controls and you want only one of them to be visible based on some IsEditing dependency property. With the build in converter, there is no easy way for achieving this functionality.

The following BooleanToVisibilityConverter solves this issues:

To use it in the above scenario:


Now, when IsEditing is false, the text block is visible. When IsEditing is true, the text block becomes collapsed and the text box is visible.

If one needs to use the Visibility.Hidden value instead of Visibility.Collapsed, the FalseValue property on the BooleanToVisibilityConverter should be set to Visibility.Hidden.

Visual Studio Addin loading but not showing in the Tools menu

Once you have created an Addin and have the addin and the dll files, moving them to the Visual Studio's Addins folder is not enough. There is a small catch, if you developed the addin on the same machine. In this case your addin probably was already set up with VS with the location where you developed the addin and by simply copying the addin to the VS' Addins folder is not enough.

VS maintains a PreloadAddinStateManaged registry key. There is an entry that relates your addin's class with its assembly path.

MyCoolAddin.Connect;C:\users\John\Documents\Visual Studio 2010\Addins\MyCoolAddin - For Testing.Addin

Now, if you rename your addin to something that makes more sense, like just MyCoolAddin.Addin (without the " - For Testing" part that VS adds just for... testing), it won't work.

The explanation is that the ext_cm_UISetup is sent only the first time the addin is loaded. And the code generated by the addin wizzard creates the Tool menu item exactly in this ext_cm_UISetup.

The solution is to run:

devenv /ResetAddin MyCoolAddin.Connect

and the put your MyCoolAddin.Addin and MyCoolAddin.dll in a folder where VS searches for Addins. (Btw, you can see these foloders in VS in Tools > Options > Environment > Add-in/Macro Security).

f.lux - software to make your life better

Just came across a small piece of software, f.lux, that changes the color temperature for the displays when the night comes. It seems pretty interesting and the author says it is very helpful. I tend to agree, though some time to accommodate with the night settings might be needed.

On the f.lux page there is also a Sleep Research that might be worth reading.

The Open File Dialog Plurality

Open a Notepad instance and check how many threads the notepad.exe creates using the Task Manager. (If the Task Manager does not show the number of threads column in the Process tab, then enable it from the View > Select Columns... menu).

One thread and 1364 KB of memory (on a Windows 7 64 bits OS).

Now, in notepad open the Open File dialog (and keep it open), and check the number of threads again.

22 threads! And 9400 KB of memory.

Now cancel  the Open File dialog. A number of 18-21 number of threads will still be there!

Is this a waste of resources? Or is this an intended waste of resources?

WM_PAINT and WM_ERASEBKGND return values

It's funny that, the return values that represents that the message was processed for the WM_PAINT and WM_ERASEBKGND messages differ. From MSDN:

WM_PAINT:

• An application returns zero if it processes this message.

WM_ERASEBKGND:

• An application should return nonzero if it erases the background; otherwise, it should return zero.

So when you try to convince Windows not to repaint in any way one window (in which you render with OpenGL for example), you get some WndProc like this:

Bind to static ObservableCollection