< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
"Vladimir" <truediogen / my-deja.com> wrote in message
news:4837660.0112170549.227501a6 / posting.google.com...
> "John Roth" <johnroth / ameritech.net> wrote in message
news:<u1npglbd5u9se3 / news.supernews.com>...
>
> > The thing is, if you can write a program that launches another
program,
> > takes over the mouse and keyboard (and game device, etc.), and
> > can take a screen shot periodically, then it can analyze the
contents of
> > the screen shot(s) and determine whether what it expected actually
> > happened. This would be a lot easier for a standard dialog box
> > application than a game, but the principle is the same.
>
> Having some test automation experience I wouldn't recommend anybody
> doing that. Far better to rewrite whole application to get it
> auto-testable or even better just sit down and test it manually.
The point I was trying to make (which seems to be universal experiance,)
is that current GUI testing tools lack a lot. It should be possible to
make
a better one (Preferably free.) Unfortunately, that's going to take a
bit of
thinking. Also a reasonable amount of pattern recognition graphics
processing.
John Roth
>
> ----
> Best Wishes,
> Vladimir