I’m now using the VistaBridge dll to get the native windows dialogs. I removed my own helper class for TaskDialogs to use the one included in the VistaBridge dll. Turns out the MS samples are full of TODO’s… Fortunately, I only needed a few things that weren’t implemented (filters in particular), so I simply added them.

Here is the new export dialog:

Much better

It took a bit longer to get going than I though it would because of a problem with the common controls dll.

To get that dialog, you have to load version 6 and the version that get loaded by default is the old version. I thought I had it fixed earlier, but one of my dll was still loading an old version, with not so nice results down the line. 

I also worked a bit on the main UI. I am now using a new template for the buttons, done by Martin Grayson. I modified it a bit so that it looks good on a glass surface. It still needs a little bit of tweaking to be perfect, but it’s ok for now. 

It nicely glows on mouse over (and it’s transparent, of course).

Corrected a bunch of problems with file and directory security today. The restore function (used when uninstalling or applying the default logon) is now working correctly.

Updated logon replacement functions. They are now working a little bit better.

Applying a logon with a background and branding images is now working. PNG files (in Bitmap section) are still resisting me, but not for long

Program for the next few days:

• Move the apply function into a thread
• Add an animation when applying a logon
• Finish the details panel
• Add the wait animation to the supported resources

Arghhhhhh. What is that ? Are they kidding or what ? WPF is supposed to be the next generation API and the only thing they provide out of the box is that ?

• Crappy Windows 95 era icons ? CHECK
• “classic” style drop down boxes and buttons ? CHECK

What a shame really. On Vista this is so lame. I hope they provide something better in the next version of WPF ! Ah well, let’s pinvoke into the new Vista APIs then… 

Luckily, they are providing samples just for that. But why not include it then? Time & quality constraints aren’t really a good excuse when it comes to things used as much as a file dialog.

Today I added drag&drop support. Now you can simply drop a logon file and it will be added to the list of logons. I also added support for logonxp format. It only took me 20 minutes from start to finish, and now logonxp files can be imported and loaded.

I had to modify the interface a bit to add capabilities support. Basically it’s a flag that the dll sets to inform the app what kind of operations it can do. The operations available are:

• Register (register and un-register the file format)
• Load (load a logon from a folder)
• Save (save a logon to a folder)
• Import (import a compressed logon file)
• Export (export a logon to a compressed file)

 For example, the logonxp dll supports loading, importing and registering.

I also worked a bit on resource replacement. Basically, as you can have HighDPI images and normal images, if one variant is available and not the other, I automatically use the one provided for both scenarios. The same is true for backgrounds. You can provide several resolutions and it will automatically choose the closest match for other resolutions. The function that does it for backgrounds is kind of limited right now and need a bit of testing but that will do it for the time being.

Not much visual work done yesterday, at least not as much as I would have wanted. I added an error background (shown when the file linked in the logon configuration doesn’t exist). I also corrected the footer (now with a correctly aligned Apply button). Finally, I added some elements to the logon preview: the user name and tile.

It’s actually the later that took me quite a lot of time. Somehow, there doesn’t seems to be a public API to programmatically get the user picture. Well, after a bit of tracing I found an exported function in shell32.dll that does just that. The only problem is that it’s not documented…

After quite a long time in the debugger, I finally had something working. Nothing surprising on the way it works, but my relative inexperience with pure win32 programming prevented me to to “get it” much sooner. And I still don’t know what one of the parameters is for. I’ll figure it out later (maybe).

On the backend side, I reorganized the class to apply an existing logon, consolidating it with the one that managed logon resources. I finally added file security & token management (I took a MS sample that nicely encapsulate token & privilege management, and added a class to take care of file access modification). 

The LogonSwitcher format supports a few elements about the logon. You can add a version, a copyright year, and an URL (both target and text to show). There is also optional support for a author logo.

Here you can see that I corrected the URL part. It was showing wrong on the last version. Turns out you have to have a textblock inside an url inside another textblock for binding to work. Otherwise, it doesn’t work right. Go figure !

I took the time to add custom selection and mouseover overlay on the logons. It’s very subtle, but I think it looks great

Not a lot of background work. Background replacement works, but not other UI elements yet. Crappy restriction on resource updating when linked with mui resources files.

 After playing with BitmapEffects a bit, it turns out it’s deadly slow when moving elements with effects applied. The panel I was using was animated on resizing and it slows down the app to a crawl every time it moves…

For WPF version 1, Microsoft hasn’t made BitmapEffects hardware accelerated, so every elements with effects applied goes back to software rendering. Not an option with animated controls, I tell you !

So the animated panel is gone, and I’m now using a simple UniformGrid. It looks so much better with a white glow for text and a dark glow for the background.

You can see that I added UI elements to the logon preview. It doesn’t look exactly like the real thing because some of the bitmaps are actually stretched and I’m not supporting that right now. The search box is now correctly aligned on the right.

On the backend size, I updated the class responsible for extracting default logon UI elements. I’m now duping almost every UI elements shown on the screen (plus a few misc. things such as the startup sound).

After almost a week of work, it’s starting to look a bit better. I didn’t work a lot on the UI so it’s still kind of messy. It’s still using an animated control as the panel to host logons, but I’m probably going to get rid of it for performance reasons (more on that in next post).

I worked on the backend for most of the week. I now have a nice plugin interface that allow FileSupport dlls to be added to support new file formats. I have rudimentary support for logonvista files, as well as it’s own file format.

Although the LogonSwitcher file format support much more than logonvista at the moment (backgrounds as well as others UI elements), it actually took a lot less time to build thank to XML serialization

I tried to make things as flexible as possible, so that I can add new UI elements without having to update every class. Hopefully it will work without too much special cases

Note: I know the logonvista is copyrighted by Stardock and they don’t allow other people to use it. I made the FileSupport dll for my one use and I don’t intend to ever distribute it.

Last week, I started working on a new application to lean WPF. Learning XAML proved to be slightly harder than I imagined. Mainly because there is no “right” way to do things. So I’ve been rewriting it almost every day, every time a little bit better than before

Here is what it looked liked after a few hours:

A little bit of customization later:

There is still a lot of work to do. I’m just starting to work on the backend. Hopefully I’ll be able to reuse some of the things I did two years ago when working on my .Net SDK for ObjectDock.

ObjectDock Docklets are DLL programmed in C or C++ that exports a few callbacks functions. These functions are called when a user manipulate the docklet. Building a docklet in .Net directly is impossible as ObjectDock doesn’t support managed code docklets. Thus, you need some kind of “proxy” that knows about .Net docklets and will be able to interact with them, relaying info to ObjectDock as needed.

Here is a picture that summarize the interactions between the different parts (I know, I could have made an UML Class diagram, but hey, it’s Christmas and I wanted a nice looking picture )

The Interop Docklet is just a normal docklet that exports all of the possible callbacks functions. Whenever a callback function is called by ObjectDock, the Interop Docklet transmits it to the currently loaded .Net Docklet. The only problem is that you cannot call managed code from unmanaged code directly, you have to use COM to access managed dlls.

Each .Net Docklet should implement the interface IDockletInterface (basically identical to the native docklet callbacks). The Interop docklet knows the GUID of the interface and can create an instance of the .Net Docklet using CoCreateInstance. However, for the call to succeed, the .net docklets have to be registered as COM objects. Asking the user to manually register each plugin with regasm was obviously not an option.

As there is no way (AFAIK) to programmatically register managed COM objects from unmanaged code, the Interop Docklet contains hardcoded info about the DotNetHelper DLL. When the docklet is called for the first time, it write that info in the registry. Then, when a CoCreateInstance call fails, it calls the RegisterDocklets function in DotNetHelper DLL that will walks through the different .Net docklets and try to register them. Problem solved (well almost, but I’ll keep that for another article )

The NetDockletHelper DLL also provides the Docklet class that encapsulate SDK functions and keeps the static data associated with each docklet (such as the docklet handle and the different folder paths). Docklet programmer can also use the LOG function from the Util class for debugging purposes.