Re: java.awt.Robot for po
To: comp.lang.java.gui
On Mar 14, 1:52 pm, Alex.From.Ohio.J...@gmail.com wrote:
On Mar 13, 6:35 pm, Andrew Thompson <andrewtho...@gmail.com> wrote:> On Ma=
r 14, 7:36 am, Alex.From.Ohio.J...@gmail.com wrote:
Thanks, Andrew.
I'm trying to use Robot to automate some work.
What work?
Does it matter?
Only as much as a solution matters. It is often
the case that people ask how to implement a strategy,
while forgetting the *goal*. There might be far
better strategies to achieve the goal.
And it seems you have given far more info. on the
goal below. So continuing..
..It's definitely not military ;)
<mock scold>
Naughty you. Don't be cheeky.
</mock scold>
Good to see you have been reading the group. :-)
(reconsiders) Actually I wrote the above statements
on the presumption you had seen a recent thread on
c.l.j.programmer in which 'military use of software'
became the bulk of the thread. If it was simply a
huge coincidence you chose to say that, my initial
statement would be less humorous. :-(
..So far it's fine except sometimes JOptionPane
What JOptionPane? Is this something in code that
is directly controlled by you, or do you just have
a binary?
By binary you mean jar file? ;) Which I can decompile and have source?
Of course I can do this but I don't need it because it's my program
and I have source.
But what makes you think that if I have code I can do whatever I want
with it? Of course I can do whatever I want but does it have sense?
Program will be overcomplicated if I add too many controls inside.
O..K. But the thing is, the overall combined system
of the application + the screenshot aspect might end
up more complex than altering the code of the original
program.
For example, in code that I control, I can get
screenshots without invoking the Robot (a
sledgehammer to crack a nut), and even do it
while the app. is sandboxed.
Further, the app. itself can far more easily
monitor the state of its GUI, and capture
screenshots as and when appropriate.
Like don't popup confirmation window if it's in test mode or something
like this.
Huhh? I'm afraid you lost me there.
..Or eliminate GUI or make it work with DSL and use this DSL
directly fr tests. I can do all this and this beauty of Java.
It's also beauty that I can eliminate all this crap and try to
interact with program by Robot and program (actually, class/object)
doesn't even know about it.
I'm afraid I missed whatever your point was,
especially when you mention DSL.
Let's say I wrote a game and want to test it for different tactics. If
I include these logics inside game it would be fine. But how can I
test random behavior of user or some mistakes like pushing wrong
button? Should I enter the code for each button - click it by mistake?
JUnit is specialised for testing GUI's.
It also uses the Robot (I expect), but that is
probably one use of the Robot that would be
justified.
With Robot it's easy.
With JUnit it would be even easier. Are you
familiar with it?
--
Andrew T.
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24