Out like a lion...

For the last week it has been mild, and often dry -- so that the daffodils and forsythia have all suddenly burst into bloom; and the weeds are going mad in the garden. But the forecast is for colder, wet and much windier weather running up to Easter.

I took the day off today to use up some carry-over leave, and to take the new wheelchair-accessible car for a spin to take Karen out to lunch; but not a long run -- so went to the Golden Ball at Boxworth, one of the usual pub-lunch haunts from work. I'm sure the process of doing all the belts, buckles, brakes, gears, etc. will get smoother with practise. And I got a bit of unexpected manoeuvring practise when heading to Knapwell, finding the road blocked with a police car and an ambulance, so having to make a 3-point turn in a very narrow lane. Still, that was all gone on the way back, and we could enjoy the vast display of daffs along the verges through the village.

Although a frequent from-work place, I'd expected that Monday would avoid the risk of running into colleagues. So imagine my surprise when the first faces I spotted as I walked through the door were they! Still, we didn't have to rush off quickly to get back for meetings at 2pm.

Restoring CompressedFolder opening for zip files

Having gotten to the point of being annoyed by the way that WinZip overwrote the association, I finally crawled around the web to find a way to restore the CompressedFolder functionality as a more convenient method for reading, even if I want finer control for writing.

Most places talking about this are mildly dodgy, want to have you drop massive slabs of stuff into your registry or say "re-install your OS". Fortunately it's easier than that.

Run regedit, and go to HKEY_CLASSES_ROOT\.zip and change the (Default) value to CompressedFolder. That restores Explore as the default option, which was what I was after.

How-To : IronPython and callback delegates with 'out' or 'ref' parameters

Following up on the earlier post, having found time to engage the brain a little...

Let's do the int flavoured version, everything non-default:

	namespace Callback
	{
	using System;
	public delegate IntPtr Hook(ref int handled);
	public static class Callback
	{
	public static object[] MakeCallback(Hook callback)
	{
	int handled = 17;
	IntPtr handle = callback(ref handled);
	return new object[] { handle, handled };
	}
	}
	}

view raw gistfile1.cs hosted with ❤ by GitHub

and then in IronPython ask the variable about itself

	import clr
	clr.AddReferenceToFile('Callback.dll')
	from Callback import *
	from System import IntPtr
	def callback(x):
	print type(x)
	print dir(x)
	return IntPtr(42)
	test = Callback.MakeCallback(callback)
	print test

view raw gistfile1.py hosted with ❤ by GitHub

Now we get

>"\Program Files\IronPython 2.6\ipy.exe" callback.py
<type 'StrongBox[int]'>
['Equals', 'GetHashCode', 'GetType', 'MemberwiseClone', 'ReferenceEquals', 'ToSt
ring', 'Value', '__class__', '__delattr__', '__doc__', '__format__', '__getattri
bute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__re
pr__', '__setattr__', '__str__', '__subclasshook__']
Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, 17))

That Value member looks interesting, so...

	import clr
	clr.AddReferenceToFile('Callback.dll')
	from Callback import *
	from System import IntPtr
	def callback(x):
	x.Value = 23
	return IntPtr(42)
	test = Callback.MakeCallback(callback)
	print test

view raw gistfile1.py hosted with ❤ by GitHub

which gives us

>"\Program Files\IronPython 2.6\ipy.exe" callback.py
Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, 23))

which is what we were looking for.

Rebuilding the C# assembly with out rather than ref and re-instating the print lines shows that the argument is still passed as a StrongBox, so there is no change on the IronPython side.

Armed with this piece of knowledge about the type, I tried Googling again, and didn't find any obvious mentions of callbacks -- just the converse matter of calling .Net methods that take out or ref parameters. But that at least is enough to reassure me that this is not just some completely undocumented hack that would be subject to change in later versions.

Note also that if I had written

print x.GetType().ToString()

(which is what I did the first time around) rather than

print type(x)

I would have gotten the result System.Int32, which gives no clue that adding

print dir(x)

is at all something worth doing.

Links for March

Programmatically detecting screen-readers.

SSL Man-in-the-Middle certificates.

.net 4:

• Changes to events.
• Workflow migration tool.

Reactive Framework:

• Drag and Drop using Rx and WPF in F#.
• Introduction in Javascript.
• JQuery integration.

Continuation passing in C#.

A fluent wrapper for System.IO.File/Path/Directory types.

TypeMock test lint.

Spring

Cycled to work again on Friday -- and then a high-speed blitz into town for a short notice appointment early afternoon. So, the tooth with a cracked filling that had been playing me up for the last few weeks is now patched until the proper fix in May.

And next week is looking plausible for more cycling.

Mowed the lawn, what there is that isn't moss, and did some spring pruning, enough to fill up the green bin, before settling. And potted up some chilli seedlings and put them into a heated propagator in the greenhouse.

Milestones

Only 35,932 this year or 5228 miles. Now some of that will be due to not having gone to the gym over the winter because of other commitments and some due to being snowed in a lot more or otherwise working from home. And probably rather more cycling

Spring

Suddenly a spell of mild dry weather -- Saturday, cycling into town for the first time in some weeks, and to the garden centre to pick up some supplies; and having my other gear cable snap while on off-road bridleway. So a bit of pushing as being stuck in top was not suited to the terrain.

Fumigated the greenhouse overnight, and then did bicycle repair -- much easier the second time around -- and put everything back on Sunday. That was warm enough to work up a bit of a sweat -- but in the greenhouse is cheating.

And today, cycled to work for the first time since mid-October; then had that first real day of T-shirt weather -- although a lot of people were still muffled up. Mild enough this evening that the central heating suddenly went from just keeping the chill off to being rather too much!

IronPython, WPF, and button-free windows

So, how do we achieve something like this with WPF, using IronPython?

Assume Vista or later (if you want to support XP, do something different if System.Environment.OSVersion.Version.Major < 6)

Start with some XAML

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window2" Height="300" Width="400" MinWidth="400" MinHeight="100"  WindowStyle="None" AllowsTransparency="True">
    <Grid>
        <Grid Name="banner">
            <Image Name="icon" Stretch="Fill" HorizontalAlignment="Left" VerticalAlignment="Top" Width="20" Height="20" Margin="4,4,0,0" />
            <Label Height="28" Name="title" VerticalAlignment="Top" Background="WhiteSmoke" Margin="28,0,0,0">Label</Label>
        </Grid>
        <StackPanel Margin="0,28,0,0" Name="body" VerticalAlignment="Top" Height="230">
            <TextBlock Height="100" Name="message" VerticalAlignment="Top" />
            <Image Name="image" Stretch="None" Height="130" Width="400" />
        </StackPanel>
        <StackPanel Name="buttons" Height="55" VerticalAlignment="Bottom" Orientation="Horizontal">
            <!-- Button Height="23" Name="button1" Width="75" Margin="2">Button</Button -->
        </StackPanel>
    </Grid>
</Window>

We can then use ctypes to get at the glass APIs, and set up some re-usable types

	from ctypes import *
	from System.Windows.Interop import WindowInteropHelper, HwndSource
	from System import IntPtr
	from System.Windows.Media import Brushes, Colors, Brush
	dwmapi = windll.dwmapi
	class __MARGINS(Structure):
	_fields_ = [("Left", c_int), ("Right", c_int), ("Top", c_int), ("Bottom", c_int)]
	def ExtendGlassFrame(window, margin):
	val = c_int()
	result = dwmapi.DwmIsCompositionEnabled(byref(val))
	success = result == 0 and not (val == 0)
	if not success:
	return False
	hwnd = WindowInteropHelper(window).Handle
	if (hwnd == IntPtr.Zero):
	return False
	window.Background = Brushes.Transparent
	HwndSource.FromHwnd(hwnd).CompositionTarget.BackgroundColor = Colors.Transparent
	margins = __MARGINS(int(margin.Left),
	int(margin.Right),
	int(margin.Top),
	int(margin.Bottom))
	result = dwmapi.DwmExtendFrameIntoClientArea(hwnd, byref(margins))
	return result == 0
	class __GlassHelper:
	def __init__(self, w, t):
	self.window = w
	self.thickness = t
	def ApplyGlass(self):
	val = ExtendGlassFrame(self.window, self.thickness)
	hwnd = WindowInteropHelper(self.window).Handle
	HwndSource.FromHwnd(hwnd).AddHook(self.__wndproc)
	def __wndproc(self, hwnd, msg, wparam, lparam, handled):
	if msg == 0x031E: ## composition changed
	handled.Value = True ## set ref argument
	ExtendGlassFrame(self.window, self.thickness)
	return IntPtr.Zero

view raw gistfile1.py hosted with ❤ by GitHub

which we can then hook into our window (assume we have loaded the XAML into a variable window)

	# make the top region glass
	window.AllowsTransparency = False
	window.Background = Brushes.Transparent
	window.FindName('title').Background = Brushes.Transparent
	thickness = Thickness(0.0, float(window.FindName('title').Height), 0.0, 0.0)
	helper = __GlassHelper(window, thickness)
	window.SourceInitialized += lambda s,e : helper.ApplyGlass()
	# make the content match what's shown in the taskbar
	window.FindName('title').Content = window.Title
	window.FindName('icon').Source = window.Icon
	# makes the window movable by press and drag
	window.MouseLeftButtonDown += lambda s,e : window.DragMove()

view raw gistfile1.py hosted with ❤ by GitHub

Of course you now need to ensure you have some button or other control that will let you dismiss the window, now you no longer have the kiss of death available at top right.

The ref parameter in the WndProc hook is the reason behind the previous post...

IronPython and callback delegates with 'out' or 'ref' parameters -- the obvious way doesn't work

The actual how-to is given here.

The only on-line documentation I could find that mentioned this has a

TODO - Delegates with out/ref parameters

about halfway down.

So, experiment time. Build callback.dll containing (or the same with 'out'):

	namespace Callback
	{
	using System;
	public delegate IntPtr Hook(ref bool handled);
	public static class Callback
	{
	public static object[] MakeCallback(Hook callback)
	{
	bool handled = false;
	IntPtr handle = callback(ref handled);
	return new object[] { handle, handled };
	}
	}
	}

view raw gistfile1.cs hosted with ❤ by GitHub

and call it from IronPython 2.6:

	import clr
	clr.AddReferenceToFile('Callback.dll')
	from Callback import *
	from System import IntPtr
	def callback(x):
	x = True
	return IntPtr(42)
	test = Callback.MakeCallback(callback)
	print test

view raw gistfile1.py hosted with ❤ by GitHub

which yields

Array[object]((<System.IntPtr object at 0x000000000000002B [42]>, False))

In sum -- it fails silently; the direct return value is fine, but mutating the actually by-value parameter does nothing.

Replacing the bool with int, and using non-default values shows that the value of a ref parameter is passed in correctly, it just can't be passed out with direct assignment.