Brian,
Thanks for your detailed report. As you no doubt have realized, Watir's
support (if it can be called that) for popups is none too good: awkward
and often unreliable. So your efforts are much appreciated. Personally,
I haven't had to deal with popups in my scripts, mostly finding ways to
avoid them. (My latest approach was the directly modify the registry
settings that control whether some of the more annoying popups appear in
the first place. This approach worked OK on XP, but failed on Vista,
which apparently has locked down access to the registry. But I digress.)
I will comment further inline to your post.
Brian Marick wrote:
> Here's the way I've found to control IE popups (asking for
> certificates, asking whether to remember passwords, etc.) on Windows
> Vista with Watir 1.5.1.1166 and nothing else:
>
> 1. Just before sending the click that will generate the popup, popen
> () a subprocess ("the watcher").
>
> 2. Have the watcher spin, checking for a window with a given title,
> then send the right keys to dismiss the window. After that, create a
> file to signal completion and exit.
>
> 3. Have the parent process spin, waiting for that file to be created,
> then continue.
>
I wonder whether this is really what is happening. My guess is that it
is blocked...
> I've not succeeded in doing it a simpler way because:
>
> 1. Putting the click() and an @autoit.WinWait in different threads
> always seems to lead to a hang. (I'm guessing I/O is happening when
> Watir is waiting for the click to finish, so the thread that wants to
> WinWait never gets started. Or the WinWait thread causes the click
> thread never to be started.)
>
Typically the click() is blocking. This amounts to a COM call and -- to
get technical for a moment -- COM requires a single-threaded apartment
(STA). Ruby, on the other hand, does not use windows threads, as a
result, COM calls block not only their thread, but all the threads in
the Ruby process. Damn!
This is why you need to have separate processes (not threads).
> 2. Windows doesn't support fork() and derivatives, so I can't just
> fork a watcher, click, and wait for the child to terminate.
>
I have been looking at the win32utils set of gems on rubyforge lately.
The win32-process gem includes a windows implementation of fork that may
be promising.
> 3. I can't even have the watcher send the "I'm done" message to its
> stdout because the parent hangs reading it, presumably for the same
> reason as threads do.
>
> My question is whether I've missed an easier or better way to do this
> using stock Watir. I'm assuming that if I dug into Win32api, I could
> find the secret to how Windows lets one process create and control
> another, but I find myself strangely without the desire to do so. But
> if someone tells me it's easy...
>
Like i said these win32utils seem to provide everything you need and
wrap a lot of the win32api nonesense, so you really would be better
looking at that.
Just today i was tweaking the jscript_test.rb Watir unit test, which
actually demonstrates several approaches for handling simple dialogs.
You should take a look at it.
I don't think you actually need to have the file polling system. The
reason why is that the click method will not return until the dialog has
been closed. So you don't need a second synchronization method.
Thanks again for sharing this. We need to think seriously about adding
this to Watir.
Bret
P.S. We have had some other comments on the choice of implementation
technology. To me, we first need an approach that is (1) reliable and
(2) intuitive and (3) supported by unit/feature tests. Once we have
this, we can experiment with different control technologies, whether
AutoIt or WSH or win32guitest or win32utils or wet-win32 or something
else. I think this puts us on the edge of #1 and #2, so the next step is
figuring a reliable way to add this to our test suite.
_______________________________________________
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
