My apologies if this has already been sent but I did not receive a post
acknowledgement.
|Tim,
|
|Thanks again. Your assistance has been extremely helpful.
|
|I've modified the test routine to illustrate the substance of our exchange
|and am posting it by way of giving something back to the grou
Tim,
Thanks again. Your assistance has been extremely helpful.
I've modified the test routine to illustrate the substance of our exchange
and am posting it by way of giving something back to the group and in the
off chance that it may prove useful to others.
BTW, I'm still a bit concerned abo
> BTW, my offer of an example still stands and I think I may
> finally have
> enough of an understanding to post something if it would be helpful to
> others.
That would be most welcome - I'd be happy to include in pywin32 and
obviously you could put if anywhere else that takes your fancy...
Chee
Richard Bell wrote:
> Is it then the case that my OnEvent routines should only execute under one
> of the following conditions?
>
> 1 - I interact with the COM target as in ie.Visible = 1 or ie.Navigate2
> 2 - I execute a pythoncom.PumpWaitingMessages
>
I believe this to be true. You are apart
Tim Roberts wrote
|It's quite possible for a single callback to happen both synchronously
|and asynchronously, depending on context. In this case, IE probably
|considers the StatusBar to be one of its "commands", so the
|OnCommandStateChange makes some sense.
Is it then the case that my OnEvent r
Richard Bell wrote:
> I rewrote the test, see below. When run it behaves as you suggest (see the
> test output below). In particular the OnVisible event occurs synchronously
> before return from 'ie.Visible = 1' as you suggested. I checked StatusBar
> and it appears to be synchronous as well. I
Tim Roberts wrote
|These are synchronous events. That is, these events are generated
|directly by the requests you made. I believe you will find that the
|"OnVisible" callback occurs before "ie.Visible = 1" returns. It's being
|handled by that same thread, which is suspended waiting for IE to
Richard Bell wrote:
> Here is some example code:
>
> --- code ---
> # test events WITHOUT a message pump
> import win32com.client
>
> class events():
> def OnVisible(self, vis):
> print 'OnVisible is:', vis
> def OnBeforeNavigate2(self,pDisp,url,flags,
> ta
Thanks Tim and Mark. I appreciate your help. BTW Mark, I'm the same
Richard Bell you helped in this area about a year ago and worked on the IE
examples in the current distribution.
Tim Roberts wrote
|Yes, that's right. I didn't see your earlier post. When did you send
|that?
It was sent on
> In casting around for a solution I poked into the code for
> DispatchWithEvents. If I understand it correctly, it is
> possible to include
> IE automation methods as part of the event class something like this:
>
> class Yie:
> --- class variables ---
> def __init__(self):
> ---
Thanks Tim.
If PumpWaitingMessages is queued AND messages can only occur when
PumpWaitingMessages is called, then Questions 2 and 3 are resolved since
absent the call to PumpWaitingMessages events can not occur.
I am still a bit concerned, however, because of an experiment I ran several
days
Richard Bell wrote:
> Question 3: Does PumpWaitingMessages insure that at MOST one message/event
> is pumped such that reentrancy is not an issue?
>
I can't answer the other two questions, but I can answer this one,
definitively yes. A Windows message queue is associated with a single
thread o
I'm continuing to work on a class to automate IE in an apartment-threaded
early binding class. The current design is relatively conventional and
looks like this:
class Yie(object):
def __init__(self, eventClass):
--- code deleted ---
self._ie = win32com.client.DispatchWithEv
13 matches
Mail list logo
