Question

So I’m writing a component in C# with events that needs to be exposed over COM to VB6.

I’ve already taken all the steps listed here, and the events themselves work fine.

However, something in the machinery of the app means that sometimes COM events aren’t delivered (when multiple events fire in close succession, only the first gets through). I’ve got to the stage of tracing data immediately before it’s raised as an event on the .net side and immediately after it’s handled on the VB side. They are not merely being queued up, or conveyed out of order (would be (more) acceptable), they are raised but not received. All events are raised from the same .net thread. When I step through the code, they are all delivered correctly; in a bare-bones test app they are all delivered even “at speed”.

So some other part of the VB app appears to be preventing these events being delivered. Where should I start looking? Can DoEvents have unintended side effects, for example?

EDIT: clarified the above that only the first of the batch is getting through.

EDIT: restated case (originally COM wrapper was believed to be the problem)

Answer 1

So 6 days of debugging later I arrived at the solution: COM events are just binned and not delivered when you’re at a breakpoint in debug mode. What I was seeing was a combination of two things:

1. The main programming loop assumed after the first event it should just continue on and do it’s thing; therefore when the other events later arrived, we were no longer calling “DoEvents” to allow them entry to the main thread; and they got delayed to the point they were irrelevant.
2. All my efforts to diagnose the situation came down to, at some point, putting a breakpoint in the code to see what was going on/step through it/ add new code to output variables etc. If I was at a breakpoint when the event was delivered, the event was just binned without being queued up.

Hopefully this can save someone else wasting this much time on such a stupid issue…