}

If you think about it for a second, the above code is a little trickier than it appears at first. Something somewhere is traversing an array of delegates and invoking each one. The invocation of this particular delegate removes the delegate from the array. Removing items from arrays that you are currently iterating through can, if handled carelessly, cause problems, no? Nonetheless, if MS had been so careless in coding the framework as to give rise to those sorts of problems, you wouldn’t trust them to .. I dunno.. collect your garbage much less any of the fancy computer stuff you count on the them for.

So with that faith in heart you come to Application.AddMessageFilter. This method allows you supposedly to get a crack at all messages posted to your app’s message loop. ( I say supposedly because all I’ve ever seemed to be able to get out of it are keyboard and mouseevents. But maybe that’s just me.) Whatever it is doing it must be working somewhat like the event sink: it’s going through the list of registered PreFilterMessage delegates and calling them. But what if you do this:

public bool PreFilterMessage(ref Message msg)
{
if(_quit)
Application.RemoveMessageFilter(this);
return false;
}

The answer is that if you’ve got any other IMessageFilter’s listening to this app, you’re dead, with the epitaph:

An unhandled exception of type ‘System.ArgumentOutOfRangeException’ occurred in mscorlib.dll

Additional information: Index was out of range. Must be non-negative and less than the size of the collection.

Very disappointing.

In our production environment we’ve gotten occasional bugs that could only be the result of double.Equals failing and, as you can see, this can actually happen. .Net optimizes double performance by taking advatage of the extended floating point facilities of the processor. Thus operations done in cpu cache may be done with a higher precision than that supported by System.Double. So when you get to a point where a comparison occurs between a number in cache and one in memory, even if they were the result of the same operation, the may not be actually equal.

Unless you absolutely can’t stand the performance hit, I would recommend using System.Decimal for operations that rely on a single standard of precision across all operations.

For more on the pitfalls of .Net floating point math go here.

As developers and good Americans of course we’re all in love with Google. Avoiding Evil is one thing, but they’ve also managed to stay away from Stupid pretty well, too. I’m a huge fan. But over the summer, when the business pages began to trumpet them as “The World’s Largest Media Company”, it sounded odd. Not only were they extraordinarily successful while giving me so much great stuff for free (Isn’t laying Golden Eggs supposed to be a terminal condition? ), but it also seems that they had gotten into the advertsing business on the side! Just as something like Google Maps realized a technological potential most of us had forgotten ever existed, they similarly resurrected the idea that you could make a lot of money on the internet by providing free services. Obviously, for those who see Google as the last best hope to make Bill Gates pay for his sins, their success is a vindication of good software and responsible business practices.

So what is the number one lesson Google’s main competitor has learned from this? Now that all the chairs have been thrown, and all the really really smart people are eating Microsoft’s lunch for free in the enemy’s cafeteria, what is the nature of this “adapt-or-die” change to the software world? Quote:

Today there are three key tenets that are driving fundamental shifts in the landscape – all of which are related in some way to services. It’s key to embrace these tenets within the context of our products and services.
1. The power of the advertising-supported economic model.
Online advertising has emerged as a significant new means by which to directly and indirectly fund the creation and delivery of software and services. In some cases, it may be possible for one to obtain more revenue through the advertising model than through a traditional licensing model. Only in its earliest stages, no one yet knows the limits of what categories of hardware, software and services, in what markets, will ultimately be funded through this model. And no one yet knows how much of the world’s online advertising revenues should or will flow to large software and service providers, medium sized or tail providers, or even users themselves.

The other two items on Ozzie’s list ( “The effectiveness of a new delivery and adoption model” and “The demand for compelling, integrated user experiences that ‘just work’) strike me as filler. The scare quotes around “just work” don’t make it seem any less awkward then it did the first time around. But for the first time working in this industry, I finally understand what services is: it’s the kind of software that can sell things to the user. It’s advertising.

I am by no means trying to say that advertising is by definition a bad thing. Some of my favorite things are brought to me by the good people at wherever. But if MS is in fact now committed to an advertising-based model, it’s fair to say that the momentum of this change to the software business is unstoppable and I think we (i.e. people who like computers and the internet) might want to go into this with our eyes wide open. It’s kind of scary that the leading edge of the discussion on what these changes may mean is going on in Redmond’s Exchange Server.

One question I’d like to hear asked is Will this make software better? Even if we’re able to meet the technical constraints posed by a Strong Server/Weak Client architecture, the fact is that user needs will now have to share resources with the needs of the customer paying the bills. If experience is any guide, the first vicitm of such a change would be a certain level “freindly hackability” that so many of us geeks hold dear in our favorite apps. We have seen what the current IP zeitgeist has wrought on stuff you thought you owned, imagine when you’re simply a guest of the Disney Corporation. Next time you’re at Space Mountain, ask them if you can drive. Also, for the past twenty years or so, vertical consolidation of media companies has been somewhat offset by the existence of the internet as a frontier of cheap production and distribution. What will be the consequences if the software industry now becomes officially part of the chain? How difficult, for example, will it be, a couple of tech generations down the road, to publish your own site without using a branded service?

Along with rich web apps and sacks of money, perhaps another of the dot com era’s internet visions is finally coming to pass at the moment we least expect it. The convergence of TV and PC. Yikes.

It’s almost enough to make you glad there’s Open Source.

The [invoked] delegate can be an instance of EventHandler, in which case the sender parameter will contain this control, and the event parameter will contain EventArgs.Empty.

I dunno… While this seems to be done in order to preserve the notion of “sender” in an eventhandler, this strikes me as a somewhat shady clause to Invoke’s contract.

The WindowsFormsParkingWindow is an orphanage for unwanted Child Controls. When you remove a Control from your form, it gets….er…parked on the WindowFormsParkingWindow. Evidently, if the removed control has focus when this happens, you’ve got a problem because the WindowsFormsParkingWindow, i.e. the Invisible, Modal (!) WindowsFormsParkingWindow, will now become active in a way nature never intended.

To avoid this, make sure you do not remove a child control while it has focus.

private void OnDataChanged(object sender, EventArgs e)
{
if(InvokeRequired)

BeginInvoke(new EventHandler(OnDataChanged), new object[] { sender, e });

else
{
……
}
}

Maybe it’s just me, but having to say “Please do whatever you need to do before you do what I’m about to tell you to do” each and every time I tell someone to do something makes me tired. On a recent project I worked on, we developed a handy strategy to avoid just this.

The key to this solution is the Windows User32 function PostMessage, which will allow you to put a message into the application’s message queue. That message will by definition, wind up received on the GUI thread. All you need is something that will listen, and means for it fire your delegate. A message only window?

Message-Only Windows

A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.

To create a message-only window, specify the HWND_MESSAGE constant or a handle to an existing message-only window in the hWndParent parameter of the CreateWindowEx function. You can also change an existing window to a message-only window by specifying HWND_MESSAGE in the hWndNewParent parameter of the SetParent function.

Our MessageWindow is then wrapped with a queue, to form a Dispatcher, whose job it is to place the delegate to be fired onto the queue and post a message to the MessageWindow, who will take it out and fire it. The last thing we need is some sort of facade or proxy for our original delegate that will allow it be invoked in such a roundabout manner.

The first step is to define an interface that our Dispatcher will use to invoke the the underlying delegate. Let’s call it STAInvoke (for Single Threaded Apartment, the threading model employed by windows forms that made all this necessary in the first place.)

Our DelegateProxy class has the following responsibilities:

— Put messages onto the Dispatcher when invoked.

— Wrap the original delegate and call DynamicInvoke on it once we are in the right thread

— Provide a factory with which you can dispense Delegates derived from proxies

The factory code looks something like this (minus exception handling):

public static Delegate CreateDelegate(Delegate dlgt)

{

DelegateProxy proxy = new DelegateProxy(dlgt,Thread.CurrentThread.ApartmentState == ApartmentState.STA);

Delegate contextdlgt = null;

contextdlgt = Delegate.CreateDelegate(dlgt.GetType(), proxy, “Invoke”);

return contextdlgt;

}

However there is some unpleasantness here. (Let’s call it a long-standing TODO.) The Invoke method on the proxy must have the same signature as your original delegate. Thus for each unique signature in the application with which you would like to use this class, you need an corresponding overload of Invoke in DelegateProxy.

So how do you use this? Let’s say your FooService has a single event, Changed, of type EventHandler. A slight modification of the usual plumbing for attaching events gives you this:

public event EventHander Changed

{

add

{

_changed += (EventHandler)STADelegate.CreateDelegate(value)

}

remove

{

_changed -= (EventHandler)STADelegate.CreateDelegate(value)

}

}

When _changed is fired then, the Invoke method of the DelegateProxy is actually called. This then looks to see if it was orginally created on the GUI thread. If it was not, it simply invokes the original delegate. If it was, it then puts itself onto the queue of the Dispatcher and posts a message into the message queue. When that message is recieved, safely in the GUI thread, the dispatcher removes the DelegateProxy from its queue and calls that DelegateProxy’s STAInvoke method.

If you feel this is a long way to go to replace a little if statement, I (sort of) understand. For me, if(InvokeRequired) BeginInvoke, sounds like some sort of obsessive-compulsive tick, rather than effective use of language. If I’d wanted to have to say things like that all day, I’d have become a lawyer.

SourceCode;

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace Lab49.Utils
{
///

///

///

///

///

}
public class MessageWindow: NativeWindow, IDisposable
{

public MessageWindow(): this(User32.WM_USER)
{

}

public MessageWindow(uint msg)
{
_msg = msg;
CreateParams createParams = new CreateParams();
createParams.Parent = (IntPtr)User32.HWND_MESSAGE;
base.CreateHandle(createParams);
}

public void Dispose()
{
base.DestroyHandle();
}

public bool Post()
{
return User32.PostMessage(this.Handle, _msg, 0, 0);

}

private uint _msg;

protected virtual void OnMessage() {}

protected override void WndProc(ref Message msg)
{
if(msg.Msg == _msg)
OnMessage();

if(msg.Msg == User32.WM_NCCREATE)
msg.Result = new IntPtr(-1);

}

}

}

More Source Code;
using System;
using System.Threading;
using System.Reflection;
using System.Windows.Forms;
using System.Collections;

namespace Lab49.Utils
{

public class STADelegate
{
static STADelegate()
{
_dispatcher = new Dispatcher();
}

public static Delegate CreateDelegate(Delegate dlgt)
{
DelegateProxy proxy = new DelegateProxy(dlgt, Thread.CurrentThread.ApartmentState == ApartmentState.STA);
Delegate contextdlgt = null;
try
{
contextdlgt = Delegate.CreateDelegate(dlgt.GetType(), proxy, “Invoke”);
}
catch(Exception ex)
{
System.Diagnostics.Debug.WriteLine(ex.ToString());
}
return contextdlgt;
}
static Dispatcher _dispatcher;
}

public class DelegateProxy: ISTASafeDelegate
{
private Delegate _dlgt;
private static Dispatcher _dispatcher;
private object[] _args;
private bool _isSTA;

static DelegateProxy()
{
_dispatcher = new Dispatcher();
}

public DelegateProxy(Delegate dlgt, bool isSTA)
{
_dlgt = dlgt;
_isSTA = isSTA;
}

public void ContextInvoke()
{
// System.Diagnostics.Debug.WriteLine(”DelegateProxy Invoked from Dispatcher: ” + AsyncDiagnostics.ThreadInfo);
_dlgt.DynamicInvoke(_args);

}

private void Invoke(params object[] args)
{
if(!_isSTA)
ContextInvoke();
_args = args;
_dispatcher.Dispatch(this);
}
private void Invoke(object sender, object[] args)
{
if(!_isSTA)
ContextInvoke();
_args = new Object[]{ sender, args };
_dispatcher.Dispatch(this);
}
private void Invoke(object retVal)
{
if(!_isSTA)
ContextInvoke();
_args = new Object[]{ retVal };
_dispatcher.Dispatch(this);
}

private void Invoke(object sender, EventArgs e)
{
if(!_isSTA)
ContextInvoke();
_args = new object[]{sender, e };
_dispatcher.Dispatch(this);
}
}

public interface ISTASafeDelegate
{
void ContextInvoke();
}

///

_operations = new Queue();

}

public void Dispatch(ISTASafeDelegate dlgt)
{
lock(_operations.SyncRoot)
{
_operations.Enqueue(dlgt);
}
// System.Diagnostics.Debug.WriteLine(”Dispatching operation to GUI Thread: ” + AsyncDiagnostics.ThreadInfo);
this.Post();
}

protected override void OnMessage()
{
// System.Diagnostics.Debug.WriteLine(”Message Rec’d: ” + AsyncDiagnostics.ThreadInfo);
ISTASafeDelegate dlgt = (ISTASafeDelegate) _operations.Dequeue();
dlgt.ContextInvoke();
}

private Queue _operations;

}

}

Update:TabMix is now located here.

In a nutshell, the main conclusions were as follows:

First, this year’s MacroVision consensus believed there is no bond bubble — at least not in the traditional sense we might think of one.

That’s especially true of government bonds, which were thought to be underpinned by generally well-behaved inflation, relatively well-positioned central banks, and a demographically inspired bid from pension funds noted below. Riskier assets — especially high-yield, emerging market, and even investment-grade corporate paper — were perceived as being more vulnerable. But any subsequent widening of spreads was not feared to be as market-disruptive an event as was the case in 1994 and again in 1998. The group felt that this would be the first Fed tightening cycle where someone didn’t go through that proverbial windshield.

Second, there was little doubt as to who would take the baton in a post-US centric world — it would be another encore for America. There was deep conviction that no one comes close to having such an ideal system — especially in terms of technology, the work force, and America’s unique risk-taking culture. Market depth and flexibility — in both the financial and the nonfinancial realms — was depicted as the icing on the cake for yet another run of US-centric global growth. Eric Chaney and I made the case for productivity convergence between the US and Europe — as America eased off on IT-enabled capital deepening just when Europe was finally getting religion on this count. A few eyebrows were raised, but there was far more skepticism than conversion. The group felt any shifts in global leadership would occur at a snail’s pace. Memories had apparently dimmed over how quickly the pendulum had swung away from Japan to Germany in the late 1980s.

Third, the demographic threat was generally not viewed as a serious problem for economies or financial markets over the next few years.

With the debate heating up on global pension reform and US social security privatization, we thought the time was finally right to grapple with this weighty issue. The group didn’t bite. They argued that this should be viewed not as a demographic problem but as more of a regulatory and political challenge that had important implications for the social policies of immigration and retirement ages. The MacroVision consensus did concede that the asset-liability mismatch has important implications for moves into long-duration fixed-income assets, but concluded that any such shifts were likely to be glacial. As one investor put it, “The demographic clock has plenty of ticks until the alarm goes off.”