Author Archive

private void button1_Click(object sender, System.EventArgs e)
{
DoItOnce();
button1.Click-=new EventHandler(button1_Click);

}

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.  Read more...

If you’ve ever wondered why many developers recommend you ALWAYS use the slow, heavy Decimal type, rather than Double when doing financials, check this out:

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.  Read more...

Not being a religious person myself, I tend to take a skeptical, detached view of the various Google vs Microsoft vs Apple vs OSS fatwahs that fill the tech blog world. (Although I am pretty certain that if the Devil had a motto, it would be “Dont Be Evil”.) Nonetheless, the past week’s combination of leaks ( the Bill Gates memo and the Ray Ozzie memo) and announcements from MS were a minor epiphany. Not so much that “Software is Dead”, but that nobody is really interested in discussing whether or not this is a good thing.  Read more...

I recently stumbled (of course) across an interesting wrinkle in Control.Invoke/BeginInvoke. From the fine print:

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.

I recently had to deal with a truly delightful bug in a Winforms app I was working on: Immediately after being clicked on, the main window would become deactivated. As my last step before calling in an exorcist, I logged WM_ACTIVATE to see if I could find the identity of the form that was being activated when this happened. Turns out I was being hijacked by something called the WindowsFormsParkingWindow.

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.  Read more...

One of the more questionable patterns in .Net Windows Forms programming is the following sort of thing:

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.)  Read more...

This addin gives you more control over tabbed browsing. (eg new window links open in new tab)

Update:TabMix is now located here.

Along the lines of Dan’s post, I thought that this was a pretty interesting research document from Morgan Stanley that came out last week.

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.

 Read more...