Help Needed on Handling Events from a Proprietary COM Object

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Help Needed on Handling Events from a Proprietary COM Object

Darren McElfresh
I’ve read through numerous posts on how to get this to work, but I’ve realized it is time to ask for help.
 
In general I have a COM object that returns an event handler:
    event_source = com_object.newEventSource( arg_data )
 
I’ve tried establishing the connection points necessary by creating an event class derived on the sink co-class of this event source:
    class Events(win32com.client.getevents(COM_LIB.CLSID)):
 
I included all of the methods that were mentioned in the generated code from makepy.  From there I tried to utilize DispatchWithEvents to connect the listener:
    event_monitor = win32com.client.DispatchWithEvents( event_source, Events )
 
Everything seems fine at this point, but when I use try to listen it never seems to fire:
    rc = win32event.WaitForSingleObject( event_monitor.event, TIME )
 
I’ve even tried (even though I don’t think it is necessary for single threaded applications):
    pythoncom.PumpWaitingMessages()
 
However that didn’t seem to have any impact either.  No matter what I try – I can’t get my handlers to fire.  I have sample code on how to do this in C++, and I have already taken the sample Java code and have my own version of that working; however I’d prefer to use Python if I can get it to work.
 
I can provide my code (or the samples), but it is somewhat lengthy so I was hoping someone would see what I was missing right away?
 
Any ideas would be appreciated.
 
Thanks,
Darren

_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Help Needed on Handling Events from a Proprietary COM Object

Mark Hammond-4
On 29/02/2012 8:26 AM, Darren McElfresh wrote:

> I’ve read through numerous posts on how to get this to work, but I’ve
> realized it is time to ask for help.
> In general I have a COM object that returns an event handler:
> /event_source = com_object.newEventSource( arg_data )/
> I’ve tried establishing the connection points necessary by creating an
> event class derived on the sink co-class of this event source:
> /class Events(win32com.client.getevents(COM_LIB.CLSID)):/
> I included all of the methods that were mentioned in the generated code
> from makepy.From there I tried to utilize DispatchWithEvents to connect
> the listener:
> /event_monitor = win32com.client.DispatchWithEvents( event_source, Events )/

Using DispatchWithEvents means you shouldn't need to use getevents
manually at all - it does the getevents for you.  So just defining your
Events class without a base-class should work - check out the docstring
for DispatchWithEvents.

> Everything seems fine at this point, but when I use try to listen it
> never seems to fire:
> /rc = win32event.WaitForSingleObject( event_monitor.event, TIME )/

What is event_monitor.event?  I guess it must be an integer event
handle, but it is worth checking it is sane.  Also, that doesn't really
make sense as an event sink - presumably you have referenced the 'event'
attribute before an event has fired, so the actual firing of an event
doesn't seem to need to do anything - it just sets the handle object and
wouldn't need to make a callback into your handler.  Generally the
firing of an event will explicitly call a method you supply, but that
doesn't seem to be the case here.

Even if that was "normal" for your object, you might need
MsgWaitForMultipleObjects - a message loop way well be needed to deliver
the event calls (ie, so the event handler functions can be called).

> I’ve even tried (even though I don’t think it is necessary for single
> threaded applications):
> /pythoncom.PumpWaitingMessages()/

A single threaded application will have to do *something* while it is
waiting for the events to fire, so unless you are in a UI like
pythonwin, you *will* need something like PumpMessages - otherwise your
thread will just terminate.  PumpWaitingMessages only pumps what is
queued now - you need PumpMessages to pump "forever" - or until you call
PostQuitMessage to kill the pump, presumably in response to a future event)

But I'm missing something - either you expect an "event" to set a
Windows event handle (and therefore probably need
MsgWaitForMultipleObjects) or you expect an "event" to make a callback
on your event handler (in which case you need something like
PumpMessages) - but the 2 scenarios are quite different depending on
what is expected to happen.

> However that didn’t seem to have any impact either.No matter what I try
> – I can’t get my handlers to fire.I have sample code on how to do this
> in C++, and I have already taken the sample Java code and have my own
> version of that working; however I’d prefer to use Python if I can get
> it to work.
> I can provide my code (or the samples), but it is somewhat lengthy so I
> was hoping someone would see what I was missing right away?

Maybe you could just provide a summary of the relevant C++ code?

Mark
_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Help Needed on Handling Events from a Proprietary COM Object

Darren McElfresh
Thanks for your help on this!

I expect an "event" to make a callback on my event handler.

I updated my code to not utilize getevents, since I'm using DispatchWithEvents, and removed my call to MsgWaitForMultipleObjects and updated the call to PumpWaitingMessages in a loop, to just be PumpMessages; however it still doesn't seem to work.

So at this point I basically have:
    class Events():
        def OnChange(self, e=defaultNamedNotOptArg):
            ....
        ....
    event_source = view.newItemEventSource( server.typeForName(server.TypeNames.CHANGEREQUEST) )
    event_monitor = win32com.client.DispatchWithEvents( event_source, Events )
    pythoncom.PumpMessages()

The C++ code snippets are the following
    class CMyListener :
   
    // _StItemSink is the default source (outgoing) dspinterface for
        // StItemEventSource objects.
        public IDispatchImpl<_IStItemSink, &DIID__IStItemSink, &LIBID_StarTeam>,
        public CComObjectRoot
    {
    public:
        CMyListener() {}
    BEGIN_COM_MAP(CMyListener)
        COM_INTERFACE_ENTRY(IDispatch)
        COM_INTERFACE_ENTRY(_IStItemSink)
    END_COM_MAP()
    ....
        // _IStItemSink is a dspinterface.
        // We must implement IDispatch::Invoke().
        STDMETHOD(Invoke)(    DISPID dispIdMember,
                            REFIID riid, LCID lcid,
                            WORD wFlags,
                            DISPPARAMS FAR* pDispParams,
                            VARIANT FAR* pVarResult,
                            EXCEPINFO FAR* pExcepInfo,
                            unsigned int FAR* puArgErr )
        {
            ....
        }
    ....
        // Create the event source for CHANGEREQUEST items.
        CComPtr<IStItemEventSource> source;
        hr = stView->newItemEventSource(type, &source);
        if (!VerifyHR(hr, IID_IStView, stView)) {
            return(false);
        }
   
        // The event source is the connection point container.
        CComPtr<IConnectionPointContainer> cpc;
        hr = source->QueryInterface(IID_IConnectionPointContainer, (void**)&cpc);
        if (!VerifyHR(hr, IID_IStItemEventSource, source)) {
            return(false);
        }
   
        // Find the connection point for Item events.
        // We save it so that we can call IConnectionPointContainer::Unadvise() later.
        hr = cpc->FindConnectionPoint(DIID__IStItemSink, &m_cp);
        if (!VerifyHR(hr, IID_IConnectionPointContainer, cpc)) {
            return(false);
        }
   
        // Instantiate our listener.
        CComObject<CMyListener>* listener = NULL;
        hr = CComObject<CMyListener>::CreateInstance(&listener);
        if (!VerifyHR(hr)) {
            return(false);
        }
   
        // Slip in a pointer to the parent dialog.
        listener->m_dlg = this;
   
        // Connect the listener.
        // We save the cookie so that we can call IConnectionPointContainer::Unadvise() later.
        hr = m_cp->Advise(listener, &m_cookie);
        if (!VerifyHR(hr, IID_IConnectionPoint, m_cp)) {
            return(false);
   
Any ideas on what I'm missing?  Is it that the object is an Dispatch Interface, and so I'm not handling that correctly?

Thanks,
Darren



From: Mark Hammond <[hidden email]>
To: Darren McElfresh <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Tuesday, February 28, 2012 5:15 PM
Subject: Re: [python-win32] Help Needed on Handling Events from a Proprietary COM Object

On 29/02/2012 8:26 AM, Darren McElfresh wrote:

> I’ve read through numerous posts on how to get this to work, but I’ve
> realized it is time to ask for help.
> In general I have a COM object that returns an event handler:
> /event_source = com_object.newEventSource( arg_data )/
> I’ve tried establishing the connection points necessary by creating an
> event class derived on the sink co-class of this event source:
> /class Events(win32com.client.getevents(COM_LIB.CLSID)):/
> I included all of the methods that were mentioned in the generated code
> from makepy.From there I tried to utilize DispatchWithEvents to connect
> the listener:
> /event_monitor = win32com.client.DispatchWithEvents( event_source, Events )/

Using DispatchWithEvents means you shouldn't need to use getevents manually at all - it does the getevents for you.  So just defining your Events class without a base-class should work - check out the docstring for DispatchWithEvents.

> Everything seems fine at this point, but when I use try to listen it
> never seems to fire:
> /rc = win32event.WaitForSingleObject( event_monitor.event, TIME )/

What is event_monitor.event?  I guess it must be an integer event handle, but it is worth checking it is sane.  Also, that doesn't really make sense as an event sink - presumably you have referenced the 'event' attribute before an event has fired, so the actual firing of an event doesn't seem to need to do anything - it just sets the handle object and wouldn't need to make a callback into your handler.  Generally the firing of an event will explicitly call a method you supply, but that doesn't seem to be the case here.

Even if that was "normal" for your object, you might need MsgWaitForMultipleObjects - a message loop way well be needed to deliver the event calls (ie, so the event handler functions can be called).

> I’ve even tried (even though I don’t think it is necessary for single
> threaded applications):
> /pythoncom.PumpWaitingMessages()/

A single threaded application will have to do *something* while it is waiting for the events to fire, so unless you are in a UI like pythonwin, you *will* need something like PumpMessages - otherwise your thread will just terminate.  PumpWaitingMessages only pumps what is queued now - you need PumpMessages to pump "forever" - or until you call PostQuitMessage to kill the pump, presumably in response to a future event)

But I'm missing something - either you expect an "event" to set a Windows event handle (and therefore probably need MsgWaitForMultipleObjects) or you expect an "event" to make a callback on your event handler (in which case you need something like PumpMessages) - but the 2 scenarios are quite different depending on what is expected to happen.

> However that didn’t seem to have any impact either.No matter what I try
> – I can’t get my handlers to fire.I have sample code on how to do this
> in C++, and I have already taken the sample Java code and have my own
> version of that working; however I’d prefer to use Python if I can get
> it to work.
> I can provide my code (or the samples), but it is somewhat lengthy so I
> was hoping someone would see what I was missing right away?

Maybe you could just provide a summary of the relevant C++ code?

Mark



_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Help Needed on Handling Events from a Proprietary COM Object

Mark Hammond-4
Sorry for the delay - I'm afraid there isn't anything obvious I can see.
  However, note that all the IConnection* interfaces are fully exposed
in Python - so it should be able to avoid the "WithEvents" type helpers
and "port" the code below directly - ie, manually doing the QI for the
IConnect* interfaces, etc.  You might find win32com/client/connect.py
and win32com/demos/connect.py useful as these do the low-level
connection-point wrangling so may either be useful directly or as a
guide to using them from Python.

Cheers,

Mark.

On 1/03/2012 1:01 AM, Darren McElfresh wrote:

> Thanks for your help on this!
>
> I expect an "event" to make a callback on my event handler.
>
> I updated my code to not utilize getevents, since I'm using
> DispatchWithEvents, and removed my call to MsgWaitForMultipleObjects and
> updated the call to PumpWaitingMessages in a loop, to just be
> PumpMessages; however it still doesn't seem to work.
>
> So at this point I basically have:
> class Events():
> def OnChange(self, e=defaultNamedNotOptArg):
> ....
> ....
> event_source = view.newItemEventSource(
> server.typeForName(server.TypeNames.CHANGEREQUEST) )
> event_monitor = win32com.client.DispatchWithEvents( event_source, Events )
> pythoncom.PumpMessages()
>
> The C++ code snippets are the following
> class CMyListener :
> // _StItemSink is the default source (outgoing) dspinterface for
> // StItemEventSource objects.
> public IDispatchImpl<_IStItemSink, &DIID__IStItemSink, &LIBID_StarTeam>,
> public CComObjectRoot
> {
> public:
> CMyListener() {}
> BEGIN_COM_MAP(CMyListener)
> COM_INTERFACE_ENTRY(IDispatch)
> COM_INTERFACE_ENTRY(_IStItemSink)
> END_COM_MAP()
> ....
> // _IStItemSink is a dspinterface.
> // We must implement IDispatch::Invoke().
> STDMETHOD(Invoke)( DISPID dispIdMember,
> REFIID riid, LCID lcid,
> WORD wFlags,
> DISPPARAMS FAR* pDispParams,
> VARIANT FAR* pVarResult,
> EXCEPINFO FAR* pExcepInfo,
> unsigned int FAR* puArgErr )
> {
> ....
> }
> ....
> // Create the event source for CHANGEREQUEST items.
> CComPtr<IStItemEventSource> source;
> hr = stView->newItemEventSource(type, &source);
> if (!VerifyHR(hr, IID_IStView, stView)) {
> return(false);
> }
>
> // The event source is the connection point container.
> CComPtr<IConnectionPointContainer> cpc;
> hr = source->QueryInterface(IID_IConnectionPointContainer, (void**)&cpc);
> if (!VerifyHR(hr, IID_IStItemEventSource, source)) {
> return(false);
> }
>
> // Find the connection point for Item events.
> // We save it so that we can call IConnectionPointContainer::Unadvise()
> later.
> hr = cpc->FindConnectionPoint(DIID__IStItemSink, &m_cp);
> if (!VerifyHR(hr, IID_IConnectionPointContainer, cpc)) {
> return(false);
> }
>
> // Instantiate our listener.
> CComObject<CMyListener>* listener = NULL;
> hr = CComObject<CMyListener>::CreateInstance(&listener);
> if (!VerifyHR(hr)) {
> return(false);
> }
>
> // Slip in a pointer to the parent dialog.
> listener->m_dlg = this;
>
> // Connect the listener.
> // We save the cookie so that we can call
> IConnectionPointContainer::Unadvise() later.
> hr = m_cp->Advise(listener, &m_cookie);
> if (!VerifyHR(hr, IID_IConnectionPoint, m_cp)) {
> return(false);
>
> Any ideas on what I'm missing? Is it that the object is an Dispatch
> Interface, and so I'm not handling that correctly?
>
> Thanks,
> Darren
>
>
> ------------------------------------------------------------------------
> *From:* Mark Hammond <[hidden email]>
> *To:* Darren McElfresh <[hidden email]>
> *Cc:* "[hidden email]" <[hidden email]>
> *Sent:* Tuesday, February 28, 2012 5:15 PM
> *Subject:* Re: [python-win32] Help Needed on Handling Events from a
> Proprietary COM Object
>
> On 29/02/2012 8:26 AM, Darren McElfresh wrote:
>  > I’ve read through numerous posts on how to get this to work, but I’ve
>  > realized it is time to ask for help.
>  > In general I have a COM object that returns an event handler:
>  > /event_source = com_object.newEventSource( arg_data )/
>  > I’ve tried establishing the connection points necessary by creating an
>  > event class derived on the sink co-class of this event source:
>  > /class Events(win32com.client.getevents(COM_LIB.CLSID)):/
>  > I included all of the methods that were mentioned in the generated code
>  > from makepy.From there I tried to utilize DispatchWithEvents to connect
>  > the listener:
>  > /event_monitor = win32com.client.DispatchWithEvents( event_source,
> Events )/
>
> Using DispatchWithEvents means you shouldn't need to use getevents
> manually at all - it does the getevents for you. So just defining your
> Events class without a base-class should work - check out the docstring
> for DispatchWithEvents.
>
>  > Everything seems fine at this point, but when I use try to listen it
>  > never seems to fire:
>  > /rc = win32event.WaitForSingleObject( event_monitor.event, TIME )/
>
> What is event_monitor.event? I guess it must be an integer event handle,
> but it is worth checking it is sane. Also, that doesn't really make
> sense as an event sink - presumably you have referenced the 'event'
> attribute before an event has fired, so the actual firing of an event
> doesn't seem to need to do anything - it just sets the handle object and
> wouldn't need to make a callback into your handler. Generally the firing
> of an event will explicitly call a method you supply, but that doesn't
> seem to be the case here.
>
> Even if that was "normal" for your object, you might need
> MsgWaitForMultipleObjects - a message loop way well be needed to deliver
> the event calls (ie, so the event handler functions can be called).
>
>  > I’ve even tried (even though I don’t think it is necessary for single
>  > threaded applications):
>  > /pythoncom.PumpWaitingMessages()/
>
> A single threaded application will have to do *something* while it is
> waiting for the events to fire, so unless you are in a UI like
> pythonwin, you *will* need something like PumpMessages - otherwise your
> thread will just terminate. PumpWaitingMessages only pumps what is
> queued now - you need PumpMessages to pump "forever" - or until you call
> PostQuitMessage to kill the pump, presumably in response to a future event)
>
> But I'm missing something - either you expect an "event" to set a
> Windows event handle (and therefore probably need
> MsgWaitForMultipleObjects) or you expect an "event" to make a callback
> on your event handler (in which case you need something like
> PumpMessages) - but the 2 scenarios are quite different depending on
> what is expected to happen.
>
>  > However that didn’t seem to have any impact either.No matter what I try
>  > – I can’t get my handlers to fire.I have sample code on how to do this
>  > in C++, and I have already taken the sample Java code and have my own
>  > version of that working; however I’d prefer to use Python if I can get
>  > it to work.
>  > I can provide my code (or the samples), but it is somewhat lengthy so I
>  > was hoping someone would see what I was missing right away?
>
> Maybe you could just provide a summary of the relevant C++ code?
>
> Mark
>
>
>
>
> _______________________________________________
> python-win32 mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-win32

_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32
Reply | Threaded
Open this post in threaded view
|

Re: Help Needed on Handling Events from a Proprietary COM Object

Darren McElfresh
Thanks.  I actually found out the problem was enabling the events within the proprietary COM object, so once I did that everything is working.  Thanks for your help!


From: Mark Hammond <[hidden email]>
To: Darren McElfresh <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: Sunday, March 4, 2012 10:18 PM
Subject: Re: [python-win32] Help Needed on Handling Events from a Proprietary COM Object

Sorry for the delay - I'm afraid there isn't anything obvious I can see.
  However, note that all the IConnection* interfaces are fully exposed
in Python - so it should be able to avoid the "WithEvents" type helpers
and "port" the code below directly - ie, manually doing the QI for the
IConnect* interfaces, etc.  You might find win32com/client/connect.py
and win32com/demos/connect.py useful as these do the low-level
connection-point wrangling so may either be useful directly or as a
guide to using them from Python.

Cheers,

Mark.

On 1/03/2012 1:01 AM, Darren McElfresh wrote:

> Thanks for your help on this!
>
> I expect an "event" to make a callback on my event handler.
>
> I updated my code to not utilize getevents, since I'm using
> DispatchWithEvents, and removed my call to MsgWaitForMultipleObjects and
> updated the call to PumpWaitingMessages in a loop, to just be
> PumpMessages; however it still doesn't seem to work.
>
> So at this point I basically have:
> class Events():
> def OnChange(self, e=defaultNamedNotOptArg):
> ....
> ....
> event_source = view.newItemEventSource(
> server.typeForName(server.TypeNames.CHANGEREQUEST) )
> event_monitor = win32com.client.DispatchWithEvents( event_source, Events )
> pythoncom.PumpMessages()
>
> The C++ code snippets are the following
> class CMyListener :
> // _StItemSink is the default source (outgoing) dspinterface for
> // StItemEventSource objects.
> public IDispatchImpl<_IStItemSink, &DIID__IStItemSink, &LIBID_StarTeam>,
> public CComObjectRoot
> {
> public:
> CMyListener() {}
> BEGIN_COM_MAP(CMyListener)
> COM_INTERFACE_ENTRY(IDispatch)
> COM_INTERFACE_ENTRY(_IStItemSink)
> END_COM_MAP()
> ....
> // _IStItemSink is a dspinterface.
> // We must implement IDispatch::Invoke().
> STDMETHOD(Invoke)( DISPID dispIdMember,
> REFIID riid, LCID lcid,
> WORD wFlags,
> DISPPARAMS FAR* pDispParams,
> VARIANT FAR* pVarResult,
> EXCEPINFO FAR* pExcepInfo,
> unsigned int FAR* puArgErr )
> {
> ....
> }
> ....
> // Create the event source for CHANGEREQUEST items.
> CComPtr<IStItemEventSource> source;
> hr = stView->newItemEventSource(type, &source);
> if (!VerifyHR(hr, IID_IStView, stView)) {
> return(false);
> }
>
> // The event source is the connection point container.
> CComPtr<IConnectionPointContainer> cpc;
> hr = source->QueryInterface(IID_IConnectionPointContainer, (void**)&cpc);
> if (!VerifyHR(hr, IID_IStItemEventSource, source)) {
> return(false);
> }
>
> // Find the connection point for Item events.
> // We save it so that we can call IConnectionPointContainer::Unadvise()
> later.
> hr = cpc->FindConnectionPoint(DIID__IStItemSink, &m_cp);
> if (!VerifyHR(hr, IID_IConnectionPointContainer, cpc)) {
> return(false);
> }
>
> // Instantiate our listener.
> CComObject<CMyListener>* listener = NULL;
> hr = CComObject<CMyListener>::CreateInstance(&listener);
> if (!VerifyHR(hr)) {
> return(false);
> }
>
> // Slip in a pointer to the parent dialog.
> listener->m_dlg = this;
>
> // Connect the listener.
> // We save the cookie so that we can call
> IConnectionPointContainer::Unadvise() later.
> hr = m_cp->Advise(listener, &m_cookie);
> if (!VerifyHR(hr, IID_IConnectionPoint, m_cp)) {
> return(false);
>
> Any ideas on what I'm missing? Is it that the object is an Dispatch
> Interface, and so I'm not handling that correctly?
>
> Thanks,
> Darren
>
>
> ------------------------------------------------------------------------
> *From:* Mark Hammond <[hidden email]>
> *To:* Darren McElfresh <[hidden email]>
> *Cc:* "[hidden email]" <[hidden email]>
> *Sent:* Tuesday, February 28, 2012 5:15 PM
> *Subject:* Re: [python-win32] Help Needed on Handling Events from a
> Proprietary COM Object
>
> On 29/02/2012 8:26 AM, Darren McElfresh wrote:
>  > I’ve read through numerous posts on how to get this to work, but I’ve
>  > realized it is time to ask for help.
>  > In general I have a COM object that returns an event handler:
>  > /event_source = com_object.newEventSource( arg_data )/
>  > I’ve tried establishing the connection points necessary by creating an
>  > event class derived on the sink co-class of this event source:
>  > /class Events(win32com.client.getevents(COM_LIB.CLSID)):/
>  > I included all of the methods that were mentioned in the generated code
>  > from makepy.From there I tried to utilize DispatchWithEvents to connect
>  > the listener:
>  > /event_monitor = win32com.client.DispatchWithEvents( event_source,
> Events )/
>
> Using DispatchWithEvents means you shouldn't need to use getevents
> manually at all - it does the getevents for you. So just defining your
> Events class without a base-class should work - check out the docstring
> for DispatchWithEvents.
>
>  > Everything seems fine at this point, but when I use try to listen it
>  > never seems to fire:
>  > /rc = win32event.WaitForSingleObject( event_monitor.event, TIME )/
>
> What is event_monitor.event? I guess it must be an integer event handle,
> but it is worth checking it is sane. Also, that doesn't really make
> sense as an event sink - presumably you have referenced the 'event'
> attribute before an event has fired, so the actual firing of an event
> doesn't seem to need to do anything - it just sets the handle object and
> wouldn't need to make a callback into your handler. Generally the firing
> of an event will explicitly call a method you supply, but that doesn't
> seem to be the case here.
>
> Even if that was "normal" for your object, you might need
> MsgWaitForMultipleObjects - a message loop way well be needed to deliver
> the event calls (ie, so the event handler functions can be called).
>
>  > I’ve even tried (even though I don’t think it is necessary for single
>  > threaded applications):
>  > /pythoncom.PumpWaitingMessages()/
>
> A single threaded application will have to do *something* while it is
> waiting for the events to fire, so unless you are in a UI like
> pythonwin, you *will* need something like PumpMessages - otherwise your
> thread will just terminate. PumpWaitingMessages only pumps what is
> queued now - you need PumpMessages to pump "forever" - or until you call
> PostQuitMessage to kill the pump, presumably in response to a future event)
>
> But I'm missing something - either you expect an "event" to set a
> Windows event handle (and therefore probably need
> MsgWaitForMultipleObjects) or you expect an "event" to make a callback
> on your event handler (in which case you need something like
> PumpMessages) - but the 2 scenarios are quite different depending on
> what is expected to happen.
>
>  > However that didn’t seem to have any impact either.No matter what I try
>  > – I can’t get my handlers to fire.I have sample code on how to do this
>  > in C++, and I have already taken the sample Java code and have my own
>  > version of that working; however I’d prefer to use Python if I can get
>  > it to work.
>  > I can provide my code (or the samples), but it is somewhat lengthy so I
>  > was hoping someone would see what I was missing right away?
>
> Maybe you could just provide a summary of the relevant C++ code?
>
> Mark
>
>
>
>
> _______________________________________________
> python-win32 mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-win32




_______________________________________________
python-win32 mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-win32