Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[scthom]

OK, I've implemented events using two different methods, and in neither case have I been able to actually receive events.  I'm hoping somebody else has tried and can help.

First way...
Using my existing plugins (ATL dll with ATL control) implemented the IMJAutomationEvents interface using IDispatchImpl and exposed the interface in the COM_INTERFACE_MAP.  Advising the source recieves an S_OK result and a valid cookie.  No events are received.  I think perhaps this one is a problem with dual IDispatchImpl interfaces (one for the main interface and one for the event sink).  I tried using CMulitDispatch from The Code Project (and based on my testing it seemed to work fine because I could expose only the IMJAutomationEvents version of IDispatch, but the Init function in the main interface would still be run) but still no events received by the handler function.

As a side note, the standard way to start an interface plugin is to use a composite control, but doing that means you can't use the SINK_MAP to set up your event handlers.  This is due to the fact that the composite control advises the sinks automatically upon activation of the control and since there is not a window yet, this fails for the event that needs to hook to MC because it hasn't attached to it yet.

So I went on to the second way...
I implemented a plain interface plugin using MFC (ActiveX control) and followed the steps in the Wiki to expose the IMJAutomationEvents interface in the interface map, set up the Dispatch map to point to the right function, etc.  Advising the source yields a valid result and cookie.  Yet, still no events recieved by the handler function.

So here's my questions...
Does MC log when it fires events?  I turned on logging in MC, but can't tell if I should be receiving anything or not.  I only have one zone, I'm changing the playlist, skipping files, etc. to try to generate events.

As far as I know, everyone else has implemented functions using VB or Delphi, but has anyone (successfully) implemented events using C++ (either ATL or MFC) ??

I can email the source to anyone who wants to take a look.  It's in VC2003 (7.1).

[scthom]

Anyone?

I know I must be really close, I just can't figure out why I'm not receiving any events.

[Craig]

Anyone?

I know I must be really close, I just can't figure out why I'm not receiving any events.

Cos you're not using Delphi? 

Seriously though, I hope you can get it working but judging by the response to my problems there's not many people trying events.

I can't see anything in my log file even when I'm recieving events from MC, maybe that would be a usefull addition.

Craig

[scthom]

Well, I've found part of the problem.

I AM finding the right connection points, and I AM getting a connection and a valid cookie.  The events are coming my way.

But, they are using fixed DispID's (1) for the event.  That probably works fine for scripting (non-dispatch aware) languages like VB and, apparantly, Delphi and Mr. Chriz's C# scripter.  But for C++, which is painfully dispatch aware, it would be much better if MC would use the GetIDsFromNames function to find the right DispID to call.

Now I just need to see if I can find a work-around.  Using ATL, it's not so obvious.  I think in MFC I can do it easily.

Gateley - any way you can change how events find their DispID -- I don't know if that will mess up the Scripters or not.  Finding Init is done correctly.

[scthom]

Update:

Well, I'm partially there.  The key was to change from a Composite control to a standard control.  Then, you just implement the IMJAutomationEvents interface using IDispEventImpl or IDispEventSimpleImpl.  Now the sink map works since it isn't called too early by the composite control.  That allows you to map the DispID (1) to the function to handle it (MJEvent).

Now I just have to work out the details of the new dialog box display.

[scthom]

Well, in a moment of inspiration (or a complete forehead-slap, either way)...

It turns out that using the composite control is, in fact, the best way to go.  So, for the record, using the ATL dll and the ATL composite control is still the easiest way to make interface plugins in C++.

The trick is to use DispEventImpl for the IMJAutomationEvents interface and the Sink_Map for the event handler, as opposed to IDispatchImpl which the wizards will want to make.  That let's you catch the fixed DispID that MC uses.

But here's the catch... in Debug mode, ATLCOM.h will throw an ASSERT error during the automatic AtlAdviseSinkMap called in the composite control's CreateWindow function.  You have to ignore it.  When compiled for release versions, it compiles away to nothing.  You still have to DispEventAdvise after you've attached to the passed dispatch pointer (m_pMJ) in Init.

All this time, and I was an "Ignore" click instead of "Debug" click away from it working.  It's like a forced march through the ATL code.  I'm becoming an ATL/COM expert but not by choice :-)

PS I never was able to get a working ActiveX control plugin using MFC as described in the Wiki.  I think that applies to out-of-proc executables, but not to in-proc DLL controls?