Huddled Masses
Archive for October, 2008
October 28th, 2008 | 
Author: This week is Microsoft’s PDC, and I, regrettably, am not there. So I’m following along from a distance, watching the keynotes live from the main site and reading a lot about Microsoft Azure Services Platform and in it’s various incarnations … and trying to follow some of the best coverage:
Oh, and don’t forget, you can watch video of every presentation 24 hours after it finishes on channel9.msdn.com
I’ve been looking at building myself a mega-media-center PC. Maybe a Linux MythTV, or Windows Vista MCE, or whatever, I haven’t really decided yet. Right now we have 3 or 4 VCRs hooked up in various rooms, and my wife tends to use a couple of them to record shows each night while we watch shows from the day before in the living room… it’s getting old. We’re constantly having problems with VCRs dying, tapes that won’t stop flipping, and so-on. So I’ve decided it’s time to go to digital recorders, but I have lots of questions.
If I bought a pair of dual-tuner TiVo boxes, they could share stuff recorded between them, but then I’m tied into a subscription? How much would that cost? I looked at Neuros OSD boxes earlier but they only have a single tuner each, so that’s a little overpriced compared to that TiVo, but it might be good for “the other rooms” if I decide to build a full PC DVR.
We actually have cable (digital cable, even), which is piped into all these different rooms in our house … and we actively watch it in at least two of those rooms (even when we don’t have guests). We also record a lot of shows —sometimes three at once— so I can’t just upgrade our Time Warner cable to include a DVR subscription. I’m thinking about building a digital video recording computer (DVRc) with multiple tuners.
The first problem is all the splitters. The signal in our house right now goes through two splitters before it gets to my digital set-top box (STB) in the living room (one to shunt a signal to the rest of the house, and one for the cable modem). Because we have a VCR in there which is sometimes used to record, we have the STB hooked up through the VCR which means that I loose the bi-directional features like “On Demand” and “Start Over.” To hook up a new multi-tuner DVR, I’ll have to add yet another (4-way) splitter! So obviously this is a problem. I think I need a boosted cable splitter (like the one on the right here) to be able to get a strong enough signal, but I don’t know, and I’m reluctant to spend this much money without being sure it will work. I need the bi-directional cable box to work, and I need the cable modem to still work. Do I need to split them off separately, and then amp the rest? Or will this thing from Amazon let them work through the splitter?
Lets assume I build a DVR PC, and I need to play video off the DVR computer to TVs in other rooms. I either need the TiVO or Neuros OSD that I mentioned earlier, or I need a Modulator like the one in the side bar (there are much cheaper versions that just merge one input to Channel 3 or 4) or, perhaps a diplexer would work. Really, the modulator seems like the perfect trick though. And would let me add more features later. There’s a huge price difference though … I need to make sure I’m not wasting my money 
But I also have some questions about tuners. Hauppauge makes some awesome tuners, including the WINTV-HVR-2250 dual-tuner (for $108) But I can get a single-tuner Hardware KWorld TV Tuner for about $32 shipped, or a software one for about $20, so I’m trying to decide if it’s worth the extra to upgrade to PCIe, to get two tuners on a single card (which might let me build a “Mini” system instead of a full ATX box). I don’t know if the digital tuner is worth the extra cash (will our Digital Cable from Time Warner have enough unencrypted QAM channels to make it worth it?
Sigh. So many choices to make. And now my server’s main HD is dead, so I don’t have the free spare hardware I thought I had to build this system with. Maybe I’ll just wait for Black Friday and see what I can get on sale…
Related articles by Zemanta
- 5 Things to Consider When Tackling DIY DVR
- MythTV, Rainy Day Project With Staying Power
- Kiss your cable box goodbye
- Hands on: Nero’s LiquidTV, TiVo for your PC
- TiVo’s Software Launches On a PC
- Return of the $14.99 HDTV tuner, now with free shipping!
- CableCARD goes two-way with new specs
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=219ec110-9f25-41dc-90db-6a598ba2876d)
I wrote yesterday about the WPF Snap-To Behavor that I created, and showed you how simple it is, but I skipped over where the magic happens, so I thought I’d go through how I created the Native Behaviors collection class, because there are a few cool tricks in here that I wanted to share with WPF developers at large (even if you’re not interested in hooking the Window Procedure).
The framework for Native Bahaviors is made up of just two classes, the first of which is basically 3 lines of code.
NativeBehavior is the abstract base class for behaviors, and consists of just definitions for the mandatory abstract GetHandlers() method (where you return an IEnumerable collection of mappings from Window Messages to your delegate methods) and the two optional (virtual) methods AddTo and RemoveFrom which are called when your behavior is initially added to a window (generally before the Window is initialized).
NativeBehaviors is an ObservableCollection of NativeBehaviors, obviously 
. But it’s ever so much more than that. First of all, it has the NativeBehaviors attached property, but it also has the code for actually hooking a WPF window to get the Window Messages, and a WndProc which processes each message against the mappings retrieved from the various NativeBehaviors that have been registered.
Lets start with the attached dependency property. There’s a very clever (and problematic) trick in the way this property is exposed. If you look at this code, you’ll see I create a private NativeBehavior dependency property, and then create public Get/Set accessors for “Behavior” which just call the NativeBehavior property. The reason for this is that if the dependency property is public, or if the public accessors even have the same name … the XAML parser finds the dependency property and uses it directly (bypassing the get/set accesors), which means you have to have an extra element in your XAML markup to initialize the NativeBehaviors collection, or you get something like this screenshot.
So instead, we hide the dependency property, and supply a getter which is backed by the dependency property. I should not that although this works great in the .Net Framework, it’s not recognized properly by all of the tools (including Resharper 4.1 and even Expression Blend), so you may have to fiddle with things.
private static readonly DependencyProperty NativeBehaviorsProperty =
DependencyProperty.RegisterAttached(
"NativeBehaviors", typeof(NativeBehaviors), typeof(NativeBehaviors),
new FrameworkPropertyMetadata(null));
// A public setter (for the non-existent "Behaviors" property)
public static void SetBehaviors(Window window, NativeBehaviors behaviors)
{
if (window == null){ throw new ArgumentNullException("window"); }
window.SetValue(NativeBehaviorsProperty, behaviors);
}
// The public getter (for the non-existent "Behaviors" property)
public static NativeBehaviors GetBehaviors(Window window)
{ // instead of GetValue, call the accessor!
return GetNativeBehaviors(window);
}
// This dependency property getter makes sure it returns a collection
private static NativeBehaviors GetNativeBehaviors(Window window)
{
if (window == null) { throw new ArgumentNullException("window"); }
// This is the plain old normal thing:
var behaviors = (NativeBehaviors)window.GetValue(NativeBehaviorsProperty);
// Our raison d'être: create a new collection if there isn't one yet
if (behaviors == null) { behaviors = new NativeBehaviors(window); }
return behaviors;
}
There’s a little more to it in the actual class source code, I’m glossing over the simplest parts, and leaving out all the XML documentation comments too. We override the CollectionChanged event so that we can hook new Behaviors as they arrive, and we make sure to hook the WndProc whenever the Target Window is set:
protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs nccea)
{
base.OnCollectionChanged(nccea);
// design mode bailout because NativeBehaviors don't work in DesignMode
if (DesignerProperties.GetIsInDesignMode(Target)) { return; }
// notify new behaviors they are being hooked up, and track their handlers
if (nccea.Action == NotifyCollectionChangedAction.Add ||
nccea.Action == NotifyCollectionChangedAction.Replace)
{
foreach (NativeBehavior behavior in nccea.NewItems)
{
behavior.AddTo(Target);
Handlers.AddRange(behavior.GetHandlers());
}
}
// notify removed behaviors they are being unhooked, and stop tracking their handlers
if (nccea.Action == NotifyCollectionChangedAction.Remove ||
nccea.Action == NotifyCollectionChangedAction.Replace)
{
foreach (NativeBehavior behavior in nccea.OldItems)
{
behavior.RemoveFrom(Target);
foreach (var h in behavior.GetHandlers())
{
Handlers.Remove(h);
}
}
}
}
// Hook the Window when its added
// but keep only a week reference to it...
public Window Target
{
get
{
if (_owner != null) {
return _owner.Target as Window;
} else return null;
}
set
{
// design mode bailout (in Design mode there's no window, and no wndproc)
if (DesignerProperties.GetIsInDesignMode(value)) { return; }
if (_owner != null && WindowHandle != IntPtr.Zero)
{
HwndSource.FromHwnd(WindowHandle).RemoveHook(WndProc);
}
Debug.Assert(null != value);
_owner = new WeakReference(value);
// Check for an HWND to determine if the Window has been loaded.
WindowHandle = new WindowInteropHelper(value).Handle;
if (IntPtr.Zero == WindowHandle)
{ // If there's no handle, set the hook when the Source is initialised.
value.SourceInitialized += (sender, e) =>
{
WindowHandle = new WindowInteropHelper((Window)sender).Handle;
// hook the WndProc
HwndSource.FromHwnd(WindowHandle).AddHook(WndProc);
};
}
else
{ // hook the WndProc
HwndSource.FromHwnd(WindowHandle).AddHook(WndProc);
}
}
}
// the weak reference to the actual window...
private WeakReference _owner;
And finally, the last part of the puzzle is my actual WndProc implementation, which has a minor drawback in that we can hypothetically have multiple behaviors which process the same window message … and may each return a different value (which we cannot reconcile). For now I’m just returning the last (non-zero) result (in actuality, all of the behaviors I’ve written thus far return zero).
private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
{
Debug.Assert(hwnd == WindowHandle); // Only expecting messages for our cached HWND.
// cast and cache the message
var message = (NativeMethods.WindowMessage)msg;
// NOTE: we may process a message multiple times
// and we have no good way to handle that...
var result = IntPtr.Zero;
foreach (var handlePair in Handlers)
{ if (handlePair.Key == message)
{
var r = handlePair.Value(wParam, lParam, ref handled);
// So, we'll return the last non-zero result (if any)
if (r != IntPtr.Zero) { result = r; }
} }
return result;
}
That pretty much covers the framework. The actual behaviors can be fairly simple like my Snap-To behavior (which is actually too simple), or extremely complex like my latest behavior, which is a port Joe Castro’s custom Window ‘Chrome’ to my behavior framework, and I’m hoping some of you will choose to write new ones and submit them as patches to the CodePlex project (for now, I’m just piggybacking it on the PoshConsole project). But in any case, the latest code is available via subversion on CodePlex, and you can download today’s snapshot here.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=2128e76c-26a5-40d9-8e1d-cd6d8ddd318f)
Posted in Huddled | 
Tags: Development, Interop, NativeBehaviors, PInvoke, Windows Presentation Foundation, WndProc, WPF | 
Comments Closed
- Image via CrunchBase
Well, Microsoft couldn’t wait until the PDC to release Silverlight 2, it’s out now! You can get Silverlight or you can get the developer version, and there’s tons of tools, including an Eclipse-based editor.
Oh, and, did you hear that the next version of Windows is going to be astonishingly named … Windows 7?
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=6a0a42a7-6937-4a27-9272-e85f092d7e07)
There are many desirable behaviors for Windows applications that are just much harder to do than they should be with the tools that Microsoft has provided in the .Net Framework. In WPF, many of these behaviors are even harder to create than in Windows Forms because the necessary hooks take a bit more work to write (thanks to the fact that there’s no window handles, so dropping down to “Native” code is harder. Luckily, WPF Attached Properties give us a whole new way to reuse these behaviors once they’re written.
I’ve started working on a few classes I’m calling NativeBehaviors, because they rely on intercepting the native Window Message processing, and I’ve put together a simple framework to let me write them, which I thought I would share. The first one I wrote is a SnapToBehavior, which implements a feature that people seem to be constantly re-implementing in apps. Basically, it makes a window snap to the screen edge when it gets close (and prevents them from being moved off-screen). I’ve also written a Global HotkeysBehavior which lets you register Hotkeys that work whenever your app is running (even if another app is active) so you can create a Hotkey to hide your app and show it, or whatever.
In the rest of this article I’ll show you how to achieve this in WPF using my base NativeBehavior class, and how to use it on a Window. Since some of you won’t really care how it works, let’s start with:
How to make your WPF Windows snap to screen edges in 3 easy steps:
Step 1. Add a reference to the Huddled.Wpf.Interop library.
Step 2. Add my Xml namespace to your root Window element
Step 3. Paste three lines from below….
<Window x:Class="GlobalHotkeys.DemoWindow" x:Name="DemoWindow"
Title="GlobalHotkeys" Height="300" Width="300"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:huddled="http://schemas.huddledmasses.org/wpf"
>
<!-- You just add a reference to the library, add the "huddled" namespace, and paste: -->
<huddled:Native.Behaviors>
<huddled:SnapToBehavior SnapDistance="20" />
</huddled:Native.Behaviors>
<!-- The rest of your window can be whatever you like. -->
<Grid>
<Label Content="Drag this window near the screen edges"/>
</Grid>
</Window>
I should point out the “SnapDistance” property of the SnapToBehavior is actually a WPF “Thickness” which lets you specify the distance from the screen edge as a single number to use on all sides, or as a separate number for each side: Left, Top, Right, Bottom. And that’s pretty much all there is to know.
How to implement a NativeBehavior.
The implementation of the SnapToBehavior is actually ridiculously simple, given the NativeBehavior framework. I simply created a SnapToBehavior class which derives from NativeBehavior, and implemented the single mandatory method:
/// <summary>
/// Gets the MessageMappings for this behavior:
/// A single mapping of a handler for WM_WINDOWPOSCHANGING.
/// </summary>
/// <returns>An enumerable collection of MessageMapping objects.</returns>
public override IEnumerable<MessageMapping> GetHandlers()
{
yield return new MessageMapping(
NativeMethods.WindowMessage.WindowPositionChanging, // the message
OnPreviewPositionChange); // the delegate which will handle that message
}
When my new behavior is added to the Behaviors collection, my handler will be registered, and whenever the WM_WINDOWPOSCHANGING message arrives, it will be called. Now I defined a DependencyProperty for the SnapDistance, so that you could set that in XAML. It’s extremely simple, and VisualStudio has a built-in snippet for dependency properties, but here’s the code:
public static readonly DependencyProperty SnapDistanceProperty =
DependencyProperty.Register(
"SnapDistance", // The name of the property (must match)
typeof(Thickness), // The type of the values
typeof(SnapToBehavior), // The type this property shows up on
new UIPropertyMetadata(new Thickness(20)) // The default value
);
public Thickness SnapDistance
{
get { return (Thickness)GetValue(SnapDistanceProperty); }
set { SetValue(SnapDistanceProperty, value); }
}
Once I have that, the last piece of the puzzle is to actually handle the window position changing message (think of it as an event, if you’re not used to Win32 message-based programming).
The basics of handling WM_WINDOWPOSCHANGING is that you get a structure passed in which has the proposed position of the Window, (including it’s z-index related to other apps) and you can basically tweak that however you like. Obviously there are lots of possibilities for this single message: always-on-bottom windows, undraggable windows, etc., but in our case we’re just concerned about how close we are to the edge.
We use the SystemParameters class to get the VirtualScreenLeft, VirtualScreenTop, and VirtualScreenWidth and VirtualScreenHeight which define the rectangle we’ll use for snapping. In the case of non-rectangular arrangements of multiple monitors this isn’t quite sufficient, but for our example anything more would be a distraction. Then we just check to see if the proposed position is within the “SnapDistance” of any of the edges, and if so, we change the position to be against the edge. That’s really all there is to it.
If you look at the code example below you’ll see I have to “Marshal” the WindowPosition structure in and out of an IntPtr which is passed in the WindowMessage … that’s the downside of intercepting window messages that the framework doesn’t already translate for us, but in this particular case, it’s actually fairly trivial.
/// <summary>lParam for WindowPositionChanging
/// </summary>
[StructLayout(LayoutKind.Sequential)]
public struct WindowPosition
{
public IntPtr Handle;
public IntPtr HandleInsertAfter;
public int Left;
public int Top;
public int Width;
public int Height;
public WindowPositionFlags Flags;
public int Right { get { return Left + Width; } }
public int Bottom { get { return Top + Height; } }
}
private IntPtr OnPreviewPositionChange(IntPtr wParam, IntPtr lParam, ref bool handled)
{
bool updated = false;
var windowPosition = (NativeMethods.WindowPosition)Marshal.PtrToStructure(lParam, typeof(NativeMethods.WindowPosition));
if ((windowPosition.Flags & NativeMethods.WindowPositionFlags.NoMove) == 0)
{
// If we use the WPF SystemParameters, these should be "Logical" pixels
Rect validArea = new Rect(SystemParameters.VirtualScreenLeft,
SystemParameters.VirtualScreenTop,
SystemParameters.VirtualScreenWidth,
SystemParameters.VirtualScreenHeight);
Rect snapToBorder = new Rect(SystemParameters.VirtualScreenLeft + SnapDistance.Left,
SystemParameters.VirtualScreenTop + SnapDistance.Top,
SystemParameters.VirtualScreenWidth - (SnapDistance.Left + SnapDistance.Right),
SystemParameters.VirtualScreenHeight - (SnapDistance.Top + SnapDistance.Bottom));
// Enforce left boundary
if (windowPosition.Left < snapToBorder.Left)
{
windowPosition.Left = (int)validArea.Left;
updated = true;
}
// Enforce top boundary
if (windowPosition.Top < snapToBorder.Y)
{
windowPosition.Top = (int)validArea.Top;
updated = true;
}
// Enforce right boundary
if (windowPosition.Right > snapToBorder.Right)
{
windowPosition.Left = (int)(validArea.Right - windowPosition.Width);
updated = true;
}
// Enforce bottom boundary
if (windowPosition.Bottom > snapToBorder.Bottom)
{
windowPosition.Top = (int)(validArea.Bottom - windowPosition.Height);
updated = true;
}
}
if (updated)
{
Marshal.StructureToPtr(windowPosition, lParam, true);
}
return IntPtr.Zero;
}
Download it, or get the source code
If you’d like, you can download the current Huddled Interop for WPF library right now, or you can check out the source from CodePlex SVN or just download the most recent commit (You are only interested in the “Huddled” project which is in the “trunk”, not the “trunk-3.5”). The source is licensed freely under the BSD or GPL v2 (and a few other licenses, see the top of the source code files).
Either way you’ll get not just the SnapToBehavior but also the global HotkeysBehavior, and the Native Behaviors framework which I’ll write more about later, but for now, in case you want to try to use it, here’s an example using both the SnapTo and HotkeysBehavior (you can find this in the GlobalHotkeys demo project, which includes some sample code for handling hotkey conflicts). Enjoy.
<Window x:Class="GlobalHotkeys.DemoWindow" x:Name="window"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:huddled="http://schemas.huddledmasses.org/wpf"
Title="Demo Window!" Height="300" Width="200"
>
<huddled:Native.Behaviors>
<huddled:SnapToBehavior SnapDistance="80,20,80,10" />
<huddled:HotkeysBehavior>
<KeyBinding Command="huddled:GlobalCommands.ActivateWindow" Key="K" Modifiers="Win" />
<KeyBinding Command="huddled:GlobalCommands.CloseWindow" Key="F4" Modifiers="Win" />
<KeyBinding Command="huddled:GlobalCommands.ToggleWindow" Key="S" Modifiers="Win" />
</huddled:HotkeysBehavior>
</huddled:Native.Behaviors>
<Grid>
<Label Content="Drag this window near the screen edges"/>
</Grid>
</Window>
Posted in Huddled |
Tags: Design, Development, GUI, Hacking, NativeBehaviors, Win32, WM_WINDOWPOSCHANGING, WPF, XAML |
Comments Closed
I just discovered ubiquity, a Firefox plugin from Mozilla labs which is really just a sort-of alpha concept preview of a new command-line interface for the web browser that they are working on.
It’s extremely cool
Ubiquity for Firefox from Aza Raskin on Vimeo.
You should watch the video, the stuff they’re doing already is kind-of exciting. It reminded me a lot of PowerShell, so I started digging around some blogs and trying to figure out where they are going, and what their inspiration is … and now I’m really quite excited about it and you should be too. Won’t it be cool when you can tell Firefox something like:
Hey Firefox? Take this text from this page, translate it to Spanish, encrypt it with my mom’s public key, email it to her … and oh yeah save this chain of commands as a new command so I can use it later.
That’s the vision of jono over at Mozilla Labs, and it sounds pretty good to me Although I couldn’t help but think that if I could access PowerShell from my browser and pipe in the selected text, I could do pretty much all of that with existing commands
Anyway, I thought I’d give you a few links to read about the concepts of expressive, composable, linguistic, and partially graphical interfaces. And then later on, I’ll show you mine.
Related articles by Zemanta
- Mozilla’s Ubiquity For Firefox Alpha 0.1 Looks Fantastic
- Ubiquity for Firefox
- Speaking Coherently
- I have seen the future – and it is called Ubiquity
- Natural Language in your Browser
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=1e94f97f-aa32-4fd7-bc12-1d0f3c0f2877)
Posted in Huddled |
Tags: Command Line, Composable, Firefox, Mozilla, Mozilla Lab, Ubiquity, User Interface |
Comments Closed