After my recent presentation at the VBUG conference, somebody sent me this question: "I have code to style a button and several triggers to change the button’s background color. For some reason, the trigger for the IsPressed property doesn’t seem to work. Why?" Here’s the style code that was being used (this actually includes some changes I made to the original, but never mind that):

<Style TargetType="{x:Type Button}">
  <Setter Property="Background" Value="Red"/>
  <Style.Triggers>
    <Trigger Property="IsMouseOver" Value="True">
      <Setter Property="Background" Value="Green"/>
    </Trigger>
    <Trigger Property="IsPressed" Value="True">
      <Setter Property="FontWeight" Value="Bold"/>
      <Setter Property="Width" Value="200" />
      <Setter Property="Background" Value="Lime" />
    </Trigger>
  </Style.Triggers>
</Style>

With a few buttons on a form and this style code installed in App.xaml, you can easily see that he’s right - the IsMouseOver property change triggers a change of the background color to green, but IsPressed seems to do its job only partly, since it misses setting the Background property to Lime. In the original example, the change to the background color in that trigger was actually the only thing that was supposed to happen, so it looked like nothing was happening at all. With my changes, it seems obvious that the trigger is observed correctly, but the Background property change doesn’t seem to be executed.

The reason for this behavior is simple: there are standard templates in place that format the buttons in the way we’re normally used to seeing a button formatted. On Vista that means setting the background color to a certain gradient, displaying a rounded rectangle, and having certain animations in place that are executed when the button is focused, the mouse moves over it or it is clicked. This standard behavior is also implemented as control templates using triggers, and so interests collide - the triggers in the sample code actually do set the background color to Green or Lime, only the standard trigger quickly starts doing something else. As a result, the IsMouseOver trigger sets the color to Green only for a short while before the standard animation sets in, and in the IsPressed case the color is actually never seen.

To solve this problem I used Blend to get hold of the standard control template for a button. I opened my test solution in Blend, selected one of my buttons and used the context menu entry Edit Control Parts (Template) | Edit a Copy… to have a block of code for the base template inserted into my XAML file. Note that this block is inserted into the Window class XAML file by default. In many cases this is actually the sensible solution, but in the sample application I had my styles defined in App.xaml, so I had to move the block across to that file. If you do this, be aware that there’s also an XML namespace Microsoft_Windows_Themes inserted by Blend, which you have to move together with the code in order to make things work.

Now, if you have a close look at this code that has been created by Blend, you will see that there are three "events" called RenderDefaulted, RenderMouseOver and RenderPressed configured to call various elements of the ButtonBase class, which are pulled in using the TemplateBinding syntax extension. In addition, there are some triggers that are also involved with changing the button’s appearance in response to various events.

For this example, I chose to remove all those elements to break things down to an extremely basic button that doesn’t react visually anymore (apart from my own triggers) to mouse moves or clicks. In reality this might not always be the right thing to do - this article is just meant as a starting point for readers to figure out what they need to do in their own use cases. Anyway, after my modifications, this is what I was left with:

<ControlTemplate x:Key="buttonTemplate" TargetType="{x:Type ButtonBase}">
  <Microsoft_Windows_Themes:ButtonChrome x:Name="Chrome"
     SnapsToDevicePixels="True"
     Background="{TemplateBinding Background}"
     BorderBrush="{TemplateBinding BorderBrush}">
    <ContentPresenter
       HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
       Margin="{TemplateBinding Padding}"
       VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
       SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}"
       Content="{TemplateBinding Content}"
       ContentTemplate="{TemplateBinding ContentTemplate}"
       RecognizesAccessKey="True"/>
  </Microsoft_Windows_Themes:ButtonChrome>
</ControlTemplate>

Blend had automatically inserted a Template attribute for this control template into XAML, to make the particular button, which I had called the context menu on, work with this template. So I just had to run the application and there it was - two buttons still working in the same way as ever, and a third one without any of the animations and perfect green and lime colors depending on mouse state. Great!

You can download the source code for my test application here: WPFControlTemplating.zip (9016 bytes)

VBUG did their Spring 2008 Conference last week. In the beginning, Andy was tired , Chris was enthusiastic and Tim was … … also there. Dave was hungry and then he couldn’t get in . When he finally made it, he was the only one in Rich’s session and had to be revived . Not quite Dave’s event - he was scared of his computer and ended up starting his own presentation early .

Mark , Gary and Rich sang , and everybody danced

In the end it was all as it should be.

Great event, guys!

Developer Express have won each of the 8 (eight!!) categories we entered for this year’s asp.netPRO Magazine Reader’s Choice Awards. Wow!

The categories we entered were Best Add-in, Best Charting and Graphics Tool, Best Component Set, Best Grid, Best Navigation Suite, Best Online Editor, Best Printing/Reporting Tool and Best Scheduling/Calendar Tool. Our overall package DXperience was also named Product of the Year.

Look here for more info, the official thank-you to everybody and a few words from Julian.

It appears I’ve managed to do a pretty stupid thing - personally I rather feel like Windows let me do a stupid thing, but that’s probably a matter of perspective

Anyway, I was trying out some things with UAC, looking at the way different elevation prompts are displayed depending on whether or not the current user is an Administrators member or not, and so on. Previously I was working in what appears to be the default configuration, which my user account being a member of the local Administrators group and the Administrator account disabled and without password.

I activated the Administrator account and gave it a password. Then I removed my own account from the Administrators group and added Power Users instead. I played around with this setup and then decided to go back where I came from - only I made a mistake, I disabled the Administrator account first, before assigning the Administrators group back to my own account.

As a result, I can’t currently find a way to get Administrator privileges on my system! I can’t log in as Administrator because the account is disabled. For the same reason I can’t use the "runas" command to run any admin tools. And elevation offers only my own account (pretty weird that - why does it offer to elevate into my own account if I’m not an Administrators member at all?), which allows me, after entering my password, to bring up Computer Management - but I still can’t make changes to any account settings, obviously.

What do I do? I can see that I wasn’t thinking enough before making those changes, but I’m still having a hard time believing that I managed to lock myself out completely, i.e. the only solution is a restore from backup. Any ideas, please?

Update: I found a solution on this very helpful page: http://www.jimmah.com/vista/Administration/locked_out_of_admin.aspx I feel quite lucky that the no. 1 option actually worked for me and I didn’t have to use any of the other two - but at least there seems to be hope even if the situation is worse than mine turned out to be. In case you need that article and the above link should have stopped working, I have a local copy of it that I might be prepared to pass on in that event. Thanks to everybody who helped!

Using Local Security Policy settings (specifically the one called "User Account Control: Switch to the secure desktop when prompting for elevation"), I can modify Vista’s behaviour when showing elevation prompts, so that the elevation dialog is simply shown as a normal window on the current desktop. I like this behaviour much better, but I’m wondering if there’s any security related reason why the so-called secure desktop is actually more secure. If you know, please tell me!

There’s a pretty big problem with shell extensions when you try to run 64 bit Windows - they either come in 64 or 32 bit varieties, and each "group" of extensions will only be loaded into a corresponding host application. In other words, Windows Explorer runs as a 64 bit executable by default and it only loads shell extensions for 64 bit. Many alternative file manager tools only come in 32 bit versions so far, and they will only load 32 bit extensions.

Some extensions come in both 32 bit and 64 bit versions, and it should be possible to install them both. I’ve seen some extensions do this automatically and then it works fine - but some other vendors distribute both versions of their products with exactly the same file naming, so you can only install either one of them.

The whole thing seems a bit stupid to me… I wonder if it wouldn’t be possible to create a 64 bit shell extension that includes the 32 bit extensions in the 64 shell. Yes, I know I can’t load the extensions directly, but I could run a separate 32 bit executable that loads them and passes over all relevant information to the 64 extension - and the other way round of course. This could work both ways actually, also enabling 64 bit extensions to be available in 32 bit hosts. Of course that’s quite a bit of information that has to be transferred very carefully, mapped correctly and so on… just the sort the thing that Microsoft could have done in Windows, probably not the sort of thing I’m going to take on myself over the next weekend.

Now, for most applications I’ve been able to use Explorer for 64 bit extensions and Altap Salamander, which I use anyway, for the 32 bit ones. But I encountered a worse kind of problem the other day, when I was trying to Anapod (brilliant iPod tool, btw - can’t begin to describe how much better than iTunes it is). Anapod comes only in a 32 bit version so far. It installed just fine and then it ran the tray application and connected to my iPod. Great. Problem was, the context menu entry I normally used to bring up Anapod Explorer and access the contents of my iPod wasn’t working - some weird error message.

After a little while, I figured out what was going on. Normally, Anapod installs a top level shell extension, which displays an icon for the iPod in the main "Computer" window in Explorer. Said context menu entry simply goes and brings up an Explorer window in the right location. Because the extension that was installed was 32 bit, my 64 bit Explorer couldn’t open a window in that location. Hm. Of course there was also no other way to get to that location from the 64 bit Explorer.

I thought for a bit and then remembered that there’s a 32 bit version of Explorer also installed on the system. By default the path to it is C:\Windows\SysWOW64\explorer.exe. I tried running it, but I still couldn’t access the Anapod shell extension. After a while I found that Task Manager listed the second running Explorer instance as 64 bit - why? I don’t really know. The funny thing is that if you watch Task Manager closely while running that version of Explorer, you’ll see that for a very short time it actually shows the "*32* marker, but then this goes away and it’s 64 bit again. I don’t have an idea why that happens - I’ve only been using 64 bit Windows for a few weeks and I don’t know anything at all about its execution model.

The solution I finally found (my apologies - I don’t remember where I found it and I didn’t store a bookmark) involves a way to run a 32 bit Explorer instance on 64 bit Windows, but it’s certainly not intuitive. To make it work, you need to create a shortcut to Explorer (I’m actually still using the SysWOW64 one, but I believe the standard one should work equally well) somewhere and then change it’s properties. Set the Target of the shortcut to this: C:\Windows\SysWOW64\explorer.exe /separate, ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}. Great, isn’t it? Again, I don’t really understand this at all, just passing it on

This solution works just fine with Anapod. I still can’t use the context menu entry to bring up the Explorer window, but with the tray tool running and the iPod connected, I just open a 32 bit instance of Explorer and browse into the iPod from there.

Just stumbled upon this due to some confusion about the version of PowerShell I was running on my 64 bit Vista machine. I ran PowerShell from the start menu, using the context menu to bring it up as Administrator. Then I set the execution policy to RemoteSigned:

Set-ExecutionPolicy RemoteSigned

I ran PowerShell as a normal user (through SlickRun - brought up the 32 bit PowerShell without me noticing at first), tried to run a script and it failed. Get-ExecutionPolicy still showed Restricted. Wtf?

Turns out that the execution policies for 32 and 64 bit PowerShells are stored separately. I don’t know, I can’t figure out any value in this apart from the obvious "let’s fuck with their minds" conspiracy idea. Probably something that wasn’t really done on purpose, but still pretty important to know.

I was fighting some problems with SlickRun for a while after installing 64 bit Vista on my machine recently. I noticed issues with powershell (SlickRun was always running the 32 bit version of it, even though the path explicitely specified the 64 bit version), and when I wanted to create a command to run SnippingTool, it turned out to be impossible… there are some very weird things going on in 64 bit Windows.

For example, Explorer shows me SnippingTool.exe in c:\windows\system32 (system32? Go figure), while my 32 bit Altap Salamander doesn’t show the same file in that location. In SlickRun it was equally impossible to configure my command to use that path, and when I tried to use the path to the start menu .lnk file instead, SlickRun’s path completion feature actually showed the .lnk file, but running it was still impossible.

After a little search, I found this forum post here, which describes an option for 64 bit systems. Quoting (I don’t trust forum content to be there when I go back later):

Try this:

• Close SlickRun
• Open C:\users\yourname\appdata\roaming\slickrun
• Edit SlickRun.ini
• In the [General] section, add the line:

                Wow64Hack=1

I activated this hack and things are better now - the PowerShell command runs the 64 bit version, and the SnippetTool can be run from it’s (alleged) c:\windows\system32 location. I still can’t use the .lnk file though, since I get a number (five or so) error message about Crypt32.dll when I try.

There are several events coming up in the next few weeks, where I’m going to be speaking. Hope to meet some of you there!

If you haven’t considered coming to any of these events, now is the time to do so - there’s lots of stuff going on, and since all of these events happen "off the beaten track", we hope to see some people there who couldn’t easily make it to the more "standard" event locations in Reading or Dublin.

Here’s where I’m going to be:

VBUG Spring Conference, Birmingham, UK - April 24th

DDD Ireland, Galway - May 3rd

DDD Scotland, Glasgow - May 10th

I believe I’m also going to be at the North East Scotland .NET User Group on May 14th, but they don’t have an announcement for the event yet. Hope to confirm that later.

I’m going to be in Seattle next week for Microsoft’s annual global MVP Summit. Would love to meet some of you there - if you see me around, please say hi, or contact me if you want to sort something out in advance.

Granted, I’m a bit late mentioning this, but I still want to do it. Microsoft gave me another MVP award in the C# category on April 1st. I’m honored - thank you very much, Microsoft, and the various people involved.

As usual, I hope to find the time one day to do a bit more blogging than I’ve done in the last year or so. At least I am finding time to do a lot of speaking at user groups and events. If I haven’t been at your group and you would like me to, feel free to contact me!