Filter Graph Spy is offering three new interfaces that provide extensibility of the spy:

• IFilterGraphAddRemoveHook
• IFilterGraphConnectHook
• IFilterGraphStateControlHook

The interfaces are contained in the type library and can be imported using #import directive. An implementation of one or more of these interfaces will receive hook style calls corresponding to respective Filter Graph Manager calls, system wide including in context of other applications.

A COM object may be registered as a hook object with Spy and NoThreadSpy COM classes under predefined registry keys:

Spy will instantiate the registered hook objects and forward them the calls it receive, before passing them to system Filter Graph Manager object. A hook object has an option to override default processing, including, for example, inserting its own filter in between. For example, IFilterGraph::Reconnect call is implemented the following way:

STDMETHOD(Reconnect)(IPin* pPin) throw()
{
    _Z4(atlTraceCOM, 4, _T("...\n"));
    HOOK_PROLOG(CFilterGraphConnectHookHost)
        OnReconnect(pT, pPin, &bDefault);
    HOOK_EPILOG()
    return m_pInnerFilterGraph2->Reconnect(pPin);
}

Before passing the call to original Reconnect method, spy is iterating through associated hooks, passing them IFilterGraphConnectHook::OnReconnect call. Setting bDefault parameter to FALSE will prevent spy from passing the call to original method.

Included BdaHooks project shows a sample implementation of the hooking COM classes (note .rgs registration).

Filter Graph Spy is compatible with all current Windows operating systems, 32-bit and 64-bit (x64), in particular including:

• Windows 7
• Windows Server 2008
• Windows Vista
• Windows Server 2003
• Windows XP
• Windows 2000

NOTE: DirectShow Filter Graph Spy is NOT suitable for production environment, it is NOT licensed to be redistributed to be a part of production state software item.

Partial Visual C++ .NET 2008 source code is available from SVN, release binary included (Win32, x64); installation instructions are in another post.

m_ComboBox.SetRedraw(FALSE);
m_ComboBox.ResetContent();
for(INT nIndex = 0; nIndex < 3; nIndex++)
    m_ComboBox.AddString(AtlFormatString(_T("Item %d"), nIndex + 1));
m_ComboBox.SetCurSel(1);
m_ComboBox.SetRedraw(TRUE)

How the combo box is going to look like?

Here it goes:

Combo box won’t repaint window on SetRedraw(TRUE) AKA WM_SETREDRAW. But once you move a mouse pointer over the control, or tab to focus it, the correct selection will be painted, “Item 2″:

The control ignores the invalidation caused by CB_SETCURSEL message while processing final SetRedraw message. To avoid GUI glitches, for example, a m_ComboBox.Invalidate() or InvalidateRect might be called after SetRedraw(TRUE).

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, &AdministratorsOwnerSecurityDescriptor)));

The code compiles fine, but on runtime it gives error 87 (ERROR_INVALID_PARAMETER, E_INVALIDARG) in the last line, returned from RegSetKeySecurity API call. My first guess was that ATL’s CSecurityDesc class for some reason prepared wrong descriptor which resulted in rejecting it as an argument. From the first glance it looks (not sure) that this class deals, to some extent, with structures itself rather than using API functions, so it could be that it results in something looking differently from expected by API calls.

Still the problem is in class itself and its cast from CSecurityDesc& to required SECURITY_DESCRIPTOR* type. The class only implements operator to automatically cast to const SECURITY_DESCRIPTOR* type, so the following line would not be passed by compiler:

Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, AdministratorsOwnerSecurityDescriptor)

However &AdministratorsOwnerSecurityDescriptor is another level of indirection and hence SECURITY_DESCRIPTOR** type, which is passed by compiler, but results in indeed invalid argument.

So in order to correctly convert CSecurityDesc& to SECURITY_DESCRIPTOR* it can be done this way:

CRegKey Key;
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.Open(HKEY_CLASSES_ROOT, pszKeyName, READ_CONTROL | WRITE_OWNER)));
CSecurityDesc AdministratorsOwnerSecurityDescriptor;
AdministratorsOwnerSecurityDescriptor.SetOwner(Sids::Admins());
ATLENSURE_SUCCEEDED(HRESULT_FROM_WIN32(Key.SetKeySecurity(OWNER_SECURITY_INFORMATION, const_cast<SECURITY_DESCRIPTOR*>((const SECURITY_DESCRIPTOR*) AdministratorsOwnerSecurityDescriptor))));

TIME_ZONE_INFORMATION:
.Bias: -120
.StandardName: FLE Standard Time
.StandardDate: { .wYear 0, .wMonth 10, .wDay 5, .wDayOfWeek 0, .wHour 4, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.StandardBias: 0
.DaylightName: FLE Daylight Time
.DaylightDate: { .wYear 0, .wMonth 3, .wDay 5, .wDayOfWeek 0, .wHour 3, .wMinute 0, .wSecond 0, .wMilliseconds 0 }
.DaylightBias: -60
[...]

A Visual C++ .NET 2008 source code is available from SVN, release binary included.

And the second utility is MonitorInformation to print multi-monitor related information again as reported by Windows, GetSystemMetrics and EnumDisplayMonitors APIs.

System Metrics:
  SM_XVIRTUALSCREEN: 0
  SM_YVIRTUALSCREEN: 0
  SM_CXVIRTUALSCREEN: 1680
  SM_CYVIRTUALSCREEN: 1050
  SM_CMONITORS: 1
  SM_SAMEDISPLAYFORMAT: 1

Monitor 0 at (0, 0) - (1680, 1050):
  Coordinates (rcMonitor): (0, 0) - (1680, 1050)
  Work Area (rcWork): (0, 0) - (1680, 1026)
  Flags (dwFlags): 0x1
  Device Name (szDevice): \\.\DISPLAY1

A Visual C++ .NET 2008 source code is available from SVN, release binary included.

The camera vendor is recognized in the industry and even considered to be among leaders, kind of “cheap for superior quality”. Their SDK/API has always been offered to reach several goals: the first was to cover product line with unified access method; the second was to embed implementation of a not so much popular TFTP protocol used for this type of hardware (rivals use more popular protocols: HTTP, RTSP). These not include regular things like to documented access to variety of features, availability for Win32 and Linux etc.

API documentation has always been not very much accurate as if it was given insufficient attention but luckily it was quite simple to figure things out. Another warning thing was that native software worked directly, without SDK: it was not very good for independent software vendors like us because there was a suspicion that SDK was something complimentary and was undertested. Fortunately however, the vendor decided to change this and their mainstream software started using the same SDK redistributables available for independent vendors also.

The first incident was recently when the vendor changed SDK implementation without changing published API and without giving any notice in documentation on one of the features. It did not break compilation or anything in our software, however it started working differently in production environment. We started receiving complaints and since we did not find any documentation changes, contacted the vendor’s support for comments and found out that implementation has been changed…

Now we got a new issue. As mentioned before, SDK’s advantage was to cover product line being constantly extended. New hardware from the product line appears to be quite sophisticated – a camera with multiple sensors. I believe this was not the thing foreseen when original SDK was designed so there was a kind of solution to workaround indexed access to individual sensor parameters in the API. However it appeared now that new products don’t support some of the older product features and SDK instead of returning a kind of “unsupported” error code to the requests, instead it messes other values. So it appeared that unified access to the product line was broken…

Everything was finally sorted out but in total it took a lot of time to. First of all, the problem due to its nature spread to production from where the dealer started receiving complaints from his client. The dealer in his turn forwarded the issue to us where we had problems investigating it because this particular piece of hardware is a kind of rare and expensive. When we gather sufficient data to think of the case as an SDK bug we forwarded the issue to the vendor.

Obviously the vendor responded with ridiculous suggestions assuming us to be complete lamers. Still we were in position to help our client and resolve the case, so spent some time to gather additional information to prove the supposition of an SDK bug. It took quite some time at our expense while finally we could work out a workaround for the problem and soon after receive a confirmation for a bug… Can we expect it to be fixed with next SDK update? “We will do this some time later”.

Why things happen this way? OK we are a small ISV with our own problems getting things work as expected. The vendor, however, is a high technology leader, well known and recognized throughout the industry, a subject of a completely different scale. Expensive hardware ans software is involved and we are still getting ridiculous problems at the output.