> If the event interface is a dual interface, you may want to try early
> invokation (generally, my approach is to try the early bound invoke, check
> for an E_NOTIMPL or just any error, then punt to the late bound call if
> necessary, when dealing with dual interfaces.)

I'll have to check into that one. Most of the code in our ATL "Fire_***"
methods were created by the ATL event wizard and modified ever so slightly
for use with the Global Interface Table. I simply went in and modified the
wizard generated code a bit here and there hoping to find the correct
solution and was going to clean up ALL of the events once/if I found the
correct solution. Thanks for the tip!

> Another possiblity is that you may be running into a case of
> multiple-dispatch interfaces being implemented. You should be QIing for

> specific event interface, not a generic IDispatch (an object may have
> multiple IDispatch implementations as it may inherit multiple dispatch
> interfaces, the only way to be sure you get the correct interface is to QI
> for the specific dispatch derived interface that you need/want.)

Hmmmm... I had also tried QIing on the event interface in another
implementation that I didn't post (due to space reasons. Would have made the
post incredibly long and boring :-) Maybe I missed something while
attempting this route but I was never able to make that work either.

> If you can post the IDL describing the relevant interfaces, it might be
> helpful (also, how did you import the information to .NET, did you use
> tlbimp, or manually describe the interfaces.)

As you requested, here is the IDL to our event interface. The methods are
declared as HRESULT but I noticed that a VB6 created OCX declares them as
"void". I tried changing them all to "void" and this seemed to fix the
problem of VB.NET wanting to implement the delegates as Functions instead of
Subs but it still didn't get me any closer to these events firing in both
VB6 and VB.NET.

helpstring("_ImxTXTSetupEvents Interface"),
dispinterface _ImxTXTSetupEvents
HRESULT NewEntity([in] ImxTXTEntity* Entity);
HRESULT EntityClick([in] ImxTXTEntities * Entities,
[in] int ClickType);
HRESULT SelectionFired([in] ImxTXTEntity * Entity);
HRESULT Click();
HRESULT DblClick();
HRESULT MouseDown([in] short Button,
[in] short Shift,
[in] long X,
[in] long Y);
HRESULT MouseMove([in] short Button,
[in] short Shift,
[in] long X,
[in] long Y);
HRESULT MouseUp([in] short Button,
[in] short Shift,
[in] long X,
[in] long Y);
HRESULT KeyDown([in, out] short* KeyCode,
[in, out] short* Shift);
HRESULT KeyUp([in, out] short* KeyCode,
[in, out] short* Shift);
HRESULT KeyPress([in, out] short* KeyASCII);
HRESULT RowColChange([in] short iRow,
[in] short iCol);


I will look into the other things that you mentioned. So far though, I think
the only reason to fix the component is so that when we sell the "toolkit"
of components, the customer will be able to use them from .NET correctly. As
it stands, I think this problem has caused .NET to get kicked out for use in
our next project that was going to build a robust client app around these
components. I would prefer to stick it out and see what the fix is but I am
not the one to make the decisions. :-(

Thanks for your help Jeff,