Hey Cüneyt & Mockey,

Thanks so much for the feedback & suggestions, much appreciated!

I will try & clarify/answer all q's in this email..

mockey_a wrote:
> You have to be careful when using HookWindowEvents. When checking 
> for classes, you have to make sure that these are somehow 
> unique. "XPCOM:EventWindow" is a generic Mozilla-class, it's a 
> message-window and it is probably used a thousand times on a 
> thousand occasions by Mozilla.
>
> As far as I understood, this script should react on prompts. Did you 
> try to use the window class of the prompt (#32770)?
>   
Yeah, I did try that, but found that it too was triggered for many 
different types of Moz windows..  at least, I think that's what I 
thought.  That is why I also further checked for particular window 
dimensions, to ensure I was definitely on right window.

But I now think I was not thinking back then.  :)

I had decided I needed to wait for the XPCOM:EventWindow to be created, 
then wait a bit, then look for the Prompt window.  That was (I think, 
from memory) because the Prompt is never actually created (at least not 
with that caption).  It only ever gets focus after an XPCOM:EventWindow 
is created, and at the time, trying to hook into the Prompt getting 
focus didn't work.

Of course, I've just tried again now & it works fine.  Probably I was 
over-confusing the matter.  Possibly too I was looking for exe==Firefox 
in the same check -- and I've just found that including that makes it 
not get triggered.

So, thanks to you guys, I've just sheared down that convoluted script to 
the following:

if (arg(1)==5 && arg(3)=="#32770" && arg(4)=="Prompt") do
    win.sendkeys("{to ^Prompt}password{en}")
    quit
endif

[I've also just realised I included my password in what I posted 
y/day...  duh]

Cüneyt wrote:
> May I suggest, that you use Autorun list instead of HookWinodwsEvents. 
> HWE has more overhead compared to Autorun and increases CPU usage. I'd 
> use HWE only sparingly.
Are you sure?  I would have thought that since the Autorun list just 
passes the params of each window event to the hook script that it was a 
negligible difference..?

Also, my HWE script is not long, with only 5 or so main events being 
watched for -- surely wouldn't take PP long to skim thru & say "not a 
match; not a match; not a match; yes a match!"..?  There's only 4 lines 
it needs to read, PP doesn't delve deeper unless it finds a match..?

> Anyway, if you can't address a window because it uses generic class 
> names or titles (DirOpus is a king here), I'd suggest you use 
> Miscplugin.
Thanks heaps for the tip & example there, Cü -- haven't looked too 
closely at MiscPlugin yet, will investigate further.

but Mockey wrote:
> This wouldn't work (OK, it might, if the EventWindow and the prompt 
> appear close together and the EventWindow was tracked). 
> 1. Karen waited for the prompt-window, but its class is #32770. 
> There is no window with the class XPCOM:EventWindow and the 
> caption "Prompt". XPCOM:EventWindow caption is always: 
> XPCOM:EventReceiver
Yes, that's why I had that messy multi-lined check, first looking for 
XPCOM:EventWindow, then waiting for a Prompt.

then Cü wrote:
> You're right. Autorun doesn't catch inivisible windows. But why try to 
> catch invisible windows, although you search for a visible password 
> prompt after all? Maybe I should have used c=#32770 (or whatever that 
> password dialog might match) as the target, then the idea behind the 
> technique would be clearer.
So right, Cü, I should be looking for the obvious first.  I had it in my 
head that I had to start my hook scriptlet by watching for new windows 
being created...  and Prompts don't get created...  so I went meandering 
around for another way.  Silly.

Cüneyt wrote:
> As far as I've seen, PP runs HWE sequentially. IMO it's not a good idea 
> to use wait's in HWE since especially Firefox does open lots lots of 
> hidden windows and closes them. So if even more hooked events occur 
> during the wait, PP may eventually run out of buffer and crash.
and Mockey wrote:
> I think there is simply a system overload because PowerPro tries to 
> run all the waits you tell it to run.
>   
> ...
> No. This would be terrible, if PowerPro could do this. What happens 
> is simply: 
> XPCOM:EventWindow is created -> PowerPro waits for prompt...
> next XPCOM:EventWindow is created -> PowerPro waits for prompt...
> next XPCOM:EventWindow is created -> PowerPro waits for prompt...
> ...
> This goes on as long as PowerPro and/or your machine allows it.
>   
Right.  Oops!  Yes, Fx opens & closes windows behind the scenes all the 
time..  man, I'm feeling really bad for my system.  No wonder Firefox 
was slow.  I thought it was due to the ridiculous number of extensions I 
have installed..  ha!!  I see now that actually I had been putting it 
under far too much unnecessary strain.

> PowerPro receives a message for every window event that is happening 
> and runs the script, i.e. it tries to run it and does its best to 
> keep up with the events. It's very likely that some concurrent 
> events are missed this way. The more complicated your script gets 
> and the more often you tell it to run something (e.g. wait), the 
> more difficult it gets for PowerPro.
>   
Thanks heaps for the explanations, Mockey & Cü!  Think I'm seeing the 
light now.
> And so, should I maybe not be using wait()s in my hook windows script?
>
> You can. But it has to make some sense.
> I use some waits in my hook-script, when I can't avoid it. E.g. I 
> have an app that creates a uniquely named class and shortly 
> afterwards a window with a unique caption becomes visible. I can 
> wait.for that without a problem. Because it will most likely happen 
> only once in a longer period.
> But that is certainly not the case for Mozilla and XPCOM:EventWindow 
> windows.
>   
Ah, right, but I disagree with your last statement -- that scenario is 
exactly what happens for Moz Prompt windows, isn't it -- first the 
XPCOM:EventWindow is created, then a Prompt window becomes visible -- 
the Prompt is never specifically created itself.

Altho you're right, the XPCOM:EventWindow is not unique in the 
slightest, huh.

>> Thanks again, Bruce, hugely appreciate the help!!
>>     
> Being not Bruce, I hope that it's not completely wrong what I'm 
> writing here. But I take that thanks nevertheless ;-)
>   
You are more than welcome -- I have more for you & Cü too, & in caps -- 
THANK YOU!!  :)

Karen



Attention: PowerPro's Web site has moved: http://www.ppro.org 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



Reply via email to