Re: Sending Events to VB6 Using Implements Keyword - debugging


<info_Seeker77@xxxxxxxxx> wrote in message
news:1124394644.778901.95610@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Brian,
>
> I waited over two hours for a response, so naturally I read with
> anticipation.....
>
> Only to find that your tone is insulting and patronising. I'm not
> impressed!
>
> The question is simple:
>
> There are basically two ways of getting events from an ATL dll to vb:
>
> 1) use connection points ("WithEvents"
>
> 2) Use an interface ("Implements")
>
> Now it isnt really that difficult to undertstand, is it, Brian?
>

Ah, so you mean the VB6 client is supplying a callback interface. This
wasn't clear to me in the OP.

> yes but ATL is a very good way of using multithreading techniques to
> get the job done in vb. Whilst vb has just one thread, the dll can have
> many. I only emphasised the point so as not to get a million replies
> about "you can only call back to vb on the vb thread itself, not from
> another". I dont want to go down this route. Its not a problem, and i
> was merely making this clear. There are about 5000+ posts about this
> problem because people dont understand vbs threading model. (e.g "my vb
> / atl app crashes when complied and not in the IDE", etc etc).
>

Your OP made no mention of the fact you are spawning a worker thread in the
ATL code, so I didn't twig to your mention of: "I make sure I am on the
correct thread through the use of a hidden window and the PostMessage
method, and it works well in compliled and IDE". Your second post (laiden
with vitriol) was very helpful in clarifying what you meant.

> So, again, my question is this:
>
> If I use connection points, the VB IDE behaves itself in debug break
> mode. The "events" are prevented from reaching the VB IDE in debug
> mode, and the code can be worked upon with ease.
>
> If I use the IDispatch interface, however, the DLL still calls the
> Implements methods in the VB IDE - often, as it turns out (they are
> from a timer, as I explained) BUT the vb ide is no longer workable; it
> stops responding.
>
> Its as if my ATL Dll needs to "know" when vb is in debug break mode, so
> it can AVOID calling the interface methods just while the op is
> debugging.
>
> I think, Brian, you have plenty of experience with ATL, but not with
> the VB IDE - so perhaps someone could reply without the snobby
> attitiude?
>

For debugging purposes, I tend to use the C++ debugger, which works quite
nicely with VB6 code. Have you given that a try? I've used it successfully
when the VB6 debugger hangs on me.

Respectfully,

Brian


.

Relevant Pages

  • Re: Console application exporting COM interface?
    ... Well...thanks brian for the shakeup. ... I already have some C code that I want to use from a VB script. ... Can you pls guide me to a tutorial abt starting an ATL ... >> find the details since all the tutorials point to the inner workings of ...
    (microsoft.public.vc.atl)
  • Re: initializing private member variables
    ... Thanks for the pointers J. W. and Brian. ... class's definition and how could I tell ATL that I wanted to initialize some ... member variables. ...
    (microsoft.public.vc.atl)
  • Re: A little conspiracy theory (extended and revised)
    ... Borland, while I argued its criticality to Borland's complete ALM/SDO ... But in the larger context I'll have to concede that Brian turned ... conceived as an ALM/SDO vendor. ... IDE lines would represent for most of those companies. ...
    (borland.public.delphi.non-technical)
  • Re: My classs FinalConstruct() not being called with ATL 7
    ... ultimately call my co class's FinalConstruct(). ... considered "incorrect" in ATL 3? ... Brian then the problem is that I inherited this larger ...
    (microsoft.public.vc.atl)
  • Re: App crashing...
    ... Probably it is crashing already in the designer generated code part. ... "Brian" wrote in message ... when I go to run it now in the IDE, ...
    (microsoft.public.dotnet.general)