Dmytro Lapshyn's Blog

Visual Studio .NET 2003's Windows Forms designer can do better than world's best magicians - it can make controls disappear from a form without any apparent reason. Anyone expecting it not to turn the development process to a magic show should read these KB articles:

http://support.microsoft.com/kb/842706/en-us

http://support.microsoft.com/kb/818220/en-us

http://support.microsoft.com/kb/911952/en-us

http://support.microsoft.com/kb/322730/en-us

My home computer's mouse practically died several days ago. And while I am quite busy to go out and buy a new one, I still have to use my home PC, so my only choice is to use the keyboard.

It was not until now when I felt what a great job Microsoft did to enable keyboard support. While I still feel somewhat awkward without the mouse, I nevertheless can access all the features I need in Windows, Outlook and Word. However, certain 3^rd party applications and Web sites are a different story - they imply that all their users utilize a pointing device. Not always the case, you know :)

Moral: If you are working on a client application, make sure the mouse and the keyboard users are equal. Go even as far as putting away your mouse and trying to use your application only with the keyboard. Believe me, your karma will be wa-a-y cleaner! ;)

I was doing a research on a COM interop question posted in microsoft.public.dotnet.framework.interop newsgroup. COM interop is known to be somewhat arcane knowledge, and MSDN seems to give only the very basics. However, there's this guy Aravind C who wrote a very detailed article on COM interop, and I recommend this article to anyone dealing with such bridging “in the trenches“:

http://www.codeproject.com/dotnet/cominterop.asp

There's another nice presentation on the same topic prepared by Andrew Troelsen himself (required Acrobat Reader or other software capable of displaying PDF documents):

http://center.org/p/docs/events/715/ComNetInterop.pdf

There are two alternatives when one needs to update a data grid's data source:

• By setting the DataSource (and probably the DataMember) properties' values.
• By using the SetDataBinding method.

In my experience, the latter is the right way. It just looks like the SetDataBinding method fully updates the grid's state, while just setting the properties does not trigger the complete internal state update sequence.

I wouldn't say that bridging non-visual .NET and COM components is an easy task, but at least this one is quite well documented nowadays. However, sometimes one needs to plug in a piece of UI developed in VB6 into a .NET client (or vice versa).

Well, I do know this is not a recommended scenario and a bad design practice. But if only all applcations we deal with were designed properly... the world would be a much better place! But since we leave in the real world, it's gonna cost us some sweat to “befriend” the legacy and the managed code.

Apparently, we need a common deniminator. And the good old window handle (HWND) will serve as the one. Both VB6 and .NET Windows Forms can easily give us the handle of a form. And both can rather easily consume Windows API. So-o... guess what? We are going one level down and employing the API level to establish the parent and child relationship between, say, the main .NET form and a child VB6 one through the SetParent API.

So, basically, what we need to do is to pass the handle of the parent window to the other side of the “bridge” and use the passed handle properly to become a “docile child”.

I was helping out a colleague with a nasty ASP .NET problem the other day. The problem we were dealing with was related to an application pool that became irresponsive once in a while. The system event log indicated some problems, but we couldn't figure out how the events logged were related to the problem itself - as usual, the event descriptions were less than helpful. At that time, the only thing I could suggest was looking up Google groups and the MS KB for any articles that could provide insight into the strange thing happening.

Several days later, I followed up with the guy and he told me they found the root cause. I am posting it here with his permission.

So, the root cause was related to the application pool being recycled too often (every 20 min. or so). Given that it was a production Web server under quite a high load, the situation was like this:

• IIS was still trying to shut down the old instance still dealing with a queue of requests
• While the old instance was still running, the new instance of the pool couldn't be started
• As a consequence, new requests were plainly rejected with a non-descriptive ASP .NET error

Morale: Watch out for IIS application pool recycle and health settings. When improperly configured, these can cause you a lot of trouble.