How to detect audio in DVR-MS files?

Just yesterday I was working on the audio detection in dvr-ms files in one software. Seeing it as a proprietary format, I didn't expect much information on dvr-ms from the ASF specification or from MSDN. Some open source projects come to rescue, and the key GUID has been discovered.

Here's how I'm doing it:

When parsing ASF_Binary_Media, if the Major Media Type is 31178c9d-03e1-4528-b5823df9db22f503, and the Format Type is 05589f81-c356-11ce-bf0100aa0055595a or c4c4c4d1-0049-4e2b-98fb9537f6ce516d, then I can expect the Format Data to be WAVEFORMATEX, padded up to Format Data Size.

Why Visual Studio Limits Me to a Specific C Runtime?

A while ago I wrote a Windows application with Visual Studio 2008. Everything went fine when tested on the development platform (Server 2003), but when I deployed it on Windows XP, the system complained that the application needed to be reinstalled.

What?

I scratched my head. My application was simple enough that it had only one executable, required no fancy installation, and I double checked that it didn't depend on anything specific to Server 2003.

In fact it did, sort of. It was linked to a version of VC runtime that doesn't ship with Windows XP, according to Dependency Walker.

How did that happen? Turned out that Visual Studio 2008 comes with this latest and greatest msvcr90.dll, and my application happened to use some C library functions. With the "right" compiler settings, msvcrt.lib (version 9) was linked in, and so I had no choice but needed this CRT to run a simple Windows application on XP.

What a great idea. An additional dll that's several times bigger than my application.

Or did I have a choice?

I could statically link the new CRT, thus only need to ship one executable file. Nah, that doesn't solve the size problem.

I could copy the old msvcrt.lib to tell VS that the application needs the old msvcrt.dll, which ships with XP, and thus eliminate the need of msvcr90.dll.

Or so I thought. Or so depends.exe said. What happened was, to use themed common controls, I told VS to include the proper manifest; and to avoid distributing yet another file, I told VS to embed (hide) the manifest in the executable. Little did I know that this manifest also included a dependency on Microsoft.VC90.CRT...

Now I could use Resource Hacker to edit that out. It would have been easier if VS allowed me to choose the version of CRT to begin with.

Of course, in the end, I started from this article and dropped the C runtime functions altogether.

How to modify PropertyGrid's internal controls?

PropertyGrid is a wonderful control. But this post is not to praise it; more to solve a practical problem.

PropertyGrid has an internal ToolStrip, among other controls. This ToolStrip provides sorting commands, but sometimes it's necessary to add other commands to it, like importing and exporting reflected data, settings, etc.

This ToolStrip is not publicly exposed, so one alternate solution is to set ToolbarVisible = false and provide a custom ToolStrip.

But wouldn't it be easier if the internal ToolStrip can be modified at will?

That can't be too hard. The following code should do:

public partial class MyPropertyGrid : System.Windows.Forms.PropertyGrid {
    public ToolStrip InternalToolStrip {
        get {
            foreach (Control ctrl in base.Controls) {
                if (ctrl is ToolStrip) {
                    return ctrl as ToolStrip;
                }
            }
            return null;
        }
    }
}

Now place MyPropertyGrid on a form, and check the Properties Window. There! Change InternalToolStrip any way seems fit.

Of course, this world ain't perfect. It's less desirable to edit this ToolStrip only from the Properties Window; plus, there's a bigger problem at runtime. They will be covered next.

RichTextBox is not a simple RichEdit wrapper?

There are several annoyances with the Rich Edit control. For example, using EM_STREAMIN / EM_STREAMOUT with EditStreamCallback will clear its undo and redo queues. Why would this caused by simply reading the stream is beyond me.

The .net RichTextBox inherits this problem, which means accessing its Text, Rtf, and Lines properties will clear the queues. What's more, calling its GetCharIndexFromPosition and GetPositionFromCharIndex functions will also clear the queues. Why is that? Don't GetCharIndexFromPosition and GetPositionFromCharIndex just wrap EM_CHARFROMPOS and EM_POSFROMCHAR?

Workarounds?

• Replace functions GetCharIndexFromPosition / GetPositionFromCharIndex with EM_CHARFROMPOS / EM_POSFROMCHAR
• Replace property Text with EM_GETTEXTEX / RichTextBox.SelectAll / SelectedText
• Replace property Lines with EM_GETTEXTEX / String.Split / Join
• Replace property Rtf with... no idea.

Why ToolStrip responses to WM_MOUSEACTIVATE differently?

When a user clicks on a .Net ToolStrip (or MsoCommandBar) on which the top-level window is not focused, the window will be focused (duh) but the ToolStrip will not process the associated mouse event. For example, when a user clicks on the New button when Microsoft Outlook is not focused, the new message dialog will not appear.

This is apparently due to the ToolStrip returning MA_ACTIVATEANDEAT on WM_MOUSEACTIVATE. I found this when I was coding my ToolStrip based tab control. A simple fix would be to return MA_ACTIVATE instead:

protected const int WM_MOUSEACTIVATE = 0x0021;
protected const int MA_ACTIVATE = 1;
protected override void WndProc(ref Message m) {
   if (m.Msg == WM_MOUSEACTIVATE) {
       m.Result = new IntPtr(MA_ACTIVATE);
       return;
   }
   base.WndProc(ref m);
}

Annoying, and won't be cross platform, but at least it works!

Will it fly?

Just bought a Micro Flyers™ Excalibur 8635R-1 couple days ago. Small, light, battery- powered, featuring double- blade rotors (top one is "stabilizer") and tail rotor, with a simple controller, anyone can be a pilot!


Or so I thought.

It's actually my first RC chopper. When I laid my hands on the controller I realized that I had no idea how to fly this thing. The throttle was too sensitive and I always crashed the black hawk seconds* after a successful† takeoff. With my !skill, I could only hold it up for another shot.

As with everything else, a little practice can help, and I'm getting better. Now I start to hate the "simplicity" of the controller, and wish it's multi-directional. But I guess for $25 I can't really ask for more...

* error C2146: syntax error : missing 'nano' before identifier 'seconds'
† #define successful 0.00000001

What's wrong with WS_EX_LAYERED and WS_EX_COMPOSITED?

From MSDN:

WS_EX_COMPOSITED

Windows XP: Paints all descendants of a window in bottom-to-top painting order using double-buffering. For more information, see Remarks. This cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.

WS_EX_LAYERED

Windows 2000/XP: Creates a layered window. Note that this cannot be used for child windows. Also, this cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.

Remarks

Windows XP: With WS_EX_COMPOSITED set, all descendants of a window get bottom-to-top painting order using double-buffering. Bottom-to-top painting order allows a descendent window to have translucency (alpha) and transparency (color-key) effects, but only if the descendent window also has the WS_EX_TRANSPARENT bit set. Double-buffering allows the window and its descendents to be painted without flicker.

If WS_EX_COMPOSITED is set on a dialog window (e.g. to reduce flickers from child windows resize), then, with the default XP theme, mouse hover on the minimize button or mouse down on the close button will have no visual feedback. It seems that the back buffer for the non client area does not get updated. One obvious workaround is to only add WS_EX_COMPOSITED on WM_ENTERSIZEMOVE and remove it on WM_EXITSIZEMOVE.

What if WS_EX_LAYERED is also set? The above workaround will not work, and worse, the client area will have all sorts of update problems: edit window will not show or receive blinking insertion point, push button will not show sunken/raised border on mouse down/up. Again it seems that the back buffer is not updated. Yet another obvious workaround is to only add WS_EX_LAYERED on WM_ENTERSIZEMOVE and remove it on WM_EXITSIZEMOVE.

What's next? I'm waiting to be hit by more poorly documented styling bugs.