DShow isn't as intimidating as it looks You create an IFilterGraph, add the filters you want, then create a ICaptureGraphBuilder2, point it at the IFilterGraph, and ask it to RenderStream You don't really have to worry about pins unless you intend to write your own source or transforms As regards IVideoWindow, yes, create your own child window and point IVideoWindow at it There are numerous examples kicking around

http://www.codeproject.com/script/Membership/View.aspx?mid=9258938[^] live video capturing & streaming[^]

Create your class as a singleton, you need to make it an event source, and the consumers an event_receiver - there's an example here on CP As far as the common variable is concerned, you can either pass it byvlaue in the event, or expose it as a property/via a method You'll have to put some locking in the singleton too, to stop your host changing the value while the clients are looking at it

You can certainly split it up, yes Some of the MFC classes are now shared with ATL, I'm not too sure about CSocket - I would guess not very easily, looking at the afxsock header

I think Disconnected Recordsets[^] may be useful to you

You need to include the ErrSupport.idl into your project, so that the TLB and H are created by the MIDL compiler, in order that your import statement works you may need also need to add an importlib in your library block too, if you want to marshal that interface The above is a precis of some comments in some of my code from a few years ago, with the following link, that may provide more help - http://groups.google.com.au/group/microsoft.public.vc.atl/browse_thread/thread/7ca944c27b0288f4/9e1752e6feb4972a?lnk=st&q=import+common+idl#9e1752e6feb4972a[^]

when you find the crash, the answer will probably present it It sounds like you have a problem you'll have to debug - again, are the pointers valid, are the parameters valid? Another option is attach to the running version, either in Visual Studio, or with WinDebug, but, again, compile without optimisations, and make sure you generate PDB files

is it crashing *inside* that call, is m_pConnection valid, are the strings valid? What is the behaviour? COM is normally very good at letting you know, via error codes, what's wrong The installer should create no differences

compile the release version with no optimisations, enable debug code in the compiler and linker, then debug it

The only other thing that comes to mind is the Dispatch pointer you're getting .. I notice you're using dispatch based callbacks into the sink? Perhaps (and i'm stabbing in the dark here ;) .Net creates your object as an aggregate object and the IDispatch you get when you query your sink, is not your's it's .NET's ?

have a look at Understanding Classic COM Interoperability With .NET Applications[^], seems to be what you're after

the obvious thing to check for is that the .net gui still has an instance of the originating com object ...

put here because I found this thread when I had a similar problem ... We had a crash in one of the comdlg32 methods wrapped in a AFX_ISOLATIONAWARE_FUNC macro, the problem was eventually traced to some shonky code in MFC, namely CDllIsolationWrapperBase::GetModuleHandle() This method uses ::GetModuleHandle to get to (in our case) comdlg32 IIF that module is already loaded - the primary distinction between ::GetModuleHandle and LoadLibrary is the upping of the refcount, done in the latter, not the former Our scenario was (simplistically) as follows ... 1. our code loads a 1st party lib, this dll explicitly loads comdlg32 2. our code uses comdlg32 methods - first time through, MFC needs a handle, uses GetModuleHandle as described above 3. our code frees 1st party lib, in its shutdown, comdlg's refcount drops to 0, hence unloads comdlg 4. our code uses comdlg32 methods again - MFC has a handle, it has a procAddress, it calls it ... boom! Obviously, this bug will exhibit similarly with all the libraries that use the MFC wrapper class

if you're using windows and dshow, this is quite easy to do with an in-place transform filter; I've used it to put timecode and DOGs on video

In the first example you're returning a reference to an object that exists *outside* the function (it was created by the caller, *before* it called the function) In the second you're returning a reference to something that no longer exists

You are stretching my point to ridicule it, so I'll qualify yours ... :-D Yes, most secure IT is used in Faraday cages for exactly the threat you highlight

i completely believe capturing the data was accidental They were capturing wireless packet headers, for sure, they don't deny that, and for a worthwhile purpose Irrespective, having an unsecured, unencrypted wireless connection, is like sun-baking naked on your driveway - you do share some responsibility if you get photographed

Couple of observations here what's the problem? what error code are you getting? what sort of help do you require? It's extremely unlikely anyone's going to copy your code, compile it and come back with the answer - sorry A general suggestion, don't use Dispatch interfaces, they are the most unwieldy method of calling com objects, use the 'real' interface Another one, if you have access to ATL, use CComPtr's to help wrap the pointers, and use OLE DB Client Templates to talk with Access

unfortunately, you don't have a lot of control

try

ShellExecute(NULL, "open", "http://www.microsoft.com", "-new", NULL, SW_SHOWNORMAL);