[This is an older post that didn't make it due to complications with Microsoft Live Spaces I don't want to go into.]

Microsoft is speeding up. A Visual Studio 2010 and .NET Framework 4.0 CTP is available, just in time for the PDC.

I'm wondering how folks are following.

1a. Migrate development, test and production environments to Vista/W2K8.

1b. Investigate 64-bit issues (interop & unmanaged).

2. Employ .NET 3.0 features: WPF, WCF, WF, click-once, smart clients, 3rd-party add-ons.

3. Investigate into Silverlight, 3rd-party add-ons.

4. Adopt .NET 3.5 language features.

5. Adopt .NET 3.5 frameworks: client application, MVC, data services, 3rd-party add-ons.

6. Parallelism and Concurrency.

7. Investigate, evaluate, and buy cloud services [from various vendors].

All that while you're actually conservatively evolving the software products you're selling to your customers which eventually must pay the bills for ALL the time you're working.

And while trying to keep a healthy work-life balance.

Unreal.

In the .NET Framework System.Windows.Forms namespace, there are many ways to set cursors:

• Cursor.Current
• Application.UseWaitCursor
• Control.UseWaitCursor, which also applies to the Form class
• Control.Cursor, which also applies to the Form class

CONSIDER indicating activity of an operation by showing the wait cursor. This provides feedback to the user that the operation started and is still in progress. This should be included by default in all UI event handlers, because the duration of an operation depends on many factors outside of the programmer's control, e.g. file access over the network.

DO NOT use the Cursor property to signal a long-running application. This property should be used only to change the cursor to indicate the action that is currently available for the control, e.g. a hand (for panning) or I-beam (to edit text).

DO use Cursor.Current = Cursor.WaitCursor before you're starting a long-running operation that does not involve user interface changes and the cursor should change immediately. The cursor will be reset automatically as soon as the current thread returns to it's message loop.

DO set UseWaitCursor to true when the target control, form, or, most commonly, the entire application execute a possibly long-running operation that involves one or more user interface changes or intermediate windows such as a progress dialog, or operations that indicate progress and completion using events. Note, that the cursor is not changed until the thread returns to the message loop. Note, that new forms do not inherit the UseWaitCursors value from Application.