how to automate java application in window using python

[meInvent bbird]

how to automate java application in window using python

1. scroll up or down of scroll bar
2. click button
3. type text in textbox

[Lawrence D’Oliveiro]

Well, don’t leave us in suspense! Give us the link to your blog post!

[kerbingamer376]

wtf?

[bream...@gmail.com]

On Thursday, September 15, 2016 at 8:13:05 AM UTC+1, meInvent bbird wrote:

Please read this http://www.catb.org/esr/faqs/smart-questions.html and then this http://sscce.org/ and then rephrase your post.

Kindest regards.

Mark Lawrence.

[meInvent bbird]

i do not have blog post,

search nothing about this in google,

is it possible to automate java application with python?

[meInvent bbird]

i find this, but it is not python, it is a product

http://sqa.stackexchange.com/questions/18134/python-based-test-automation-tools-for-desktop-applications

[Lawrence D’Oliveiro]

On Friday, September 16, 2016 at 6:55:07 PM UTC+12, meInvent bbird wrote:
> On Thursday, September 15, 2016 at 3:52:41 PM UTC+8, Lawrence D’Oliveiro
> wrote:
>> On Thursday, September 15, 2016 at 7:13:05 PM UTC+12, meInvent bbird
>> wrote:
>>> how to automate java application in window using python
>>>
>>> 1. scroll up or down of scroll bar
>>> 2. click button
>>> 3. type text in textbox
>>
>> Well, don’t leave us in suspense! Give us the link to your blog post!
>
> i do not have blog post,

Oh, now you make us sad. I thought you were promoting a blog post where you tell us “how to automate java application in window using python” using just 3 steps! But it turns out you have nothing. You are an empty promiser.

[Christian Gollwitzer]

Am 16.09.16 um 09:01 schrieb Lawrence D’Oliveiro:

You are being mean. It is quite evident that English is not his first
language, and highly probable that this was actually the question "How
do I automate a Java application using Python?"

I don't have a real answer myself, but maybe using Jython one can get
access to the Java objects underlying the application (and then, of
course, execute methods of the GUI objects). This depends on the GUI
toolkit (Swing/SWT) and knowledge of the applications' structure, of
course. Another (less robust) way of desktop automation is Sikuli
http://www.sikuli.org/ (Windows only, I think)

Christian

[meInvent bbird]

you are right, english is not my first language

i just talk as simple as i can, i do not know previous talking is mean

[Fabio Zadrozny]

Take a look at https://pyautogui.readthedocs.io/en/latest/

On Fri, Sep 16, 2016 at 9:24 AM, meInvent bbird <jobma...@gmail.com>
wrote:

> --
> https://mail.python.org/mailman/listinfo/python-list
>

[vern...@gmail.com]

On Thursday, September 15, 2016 at 11:57:04 PM UTC-7, meInvent bbird wrote:
> On Friday, September 16, 2016 at 2:26:47 AM UTC+8, bream...@gmail.com wrote:
> > On Thursday, September 15, 2016 at 8:13:05 AM UTC+1, meInvent bbird wrote:
> > > how to automate java application in window using python
> > >
> > > 1. scroll up or down of scroll bar
> > > 2. click button
> > > 3. type text in textbox
> >

Check out Sikuli at www.sikuli.org. It uses Jython, but hopefully that is close enough.

Best, Vern

[Lawrence D’Oliveiro]

On Friday, September 16, 2016 at 10:22:34 PM UTC+12, Christian Gollwitzer wrote:
> "How do I automate a Java application using Python?"

Which is really a meaningless question. “Automation” is what computer programs do. (Assuming “application” is just another word for “program”.) If the program doesn’t work the way you expect, fix it.

But then, “automation” and “GUI” never really went together, did they <http://ldo17.tumblr.com/post/104365910477/cli-versus-gui-deathmatch> ...

[Gregory Ewing]

Lawrence D’Oliveiro wrote:
> On Friday, September 16, 2016 at 10:22:34 PM UTC+12, Christian Gollwitzer
> wrote:
>
>> "How do I automate a Java application using Python?"
>
> Which is really a meaningless question. “Automation” is what computer
> programs do.

It's not meaningless. The term "automation" is frequently
used in the Windows world to mean programming something that
you would otherwise do manually through a GUI, and that's
clearly the sense in which it's being used here.

--
Greg

[Lawrence D’Oliveiro]

On Sunday, September 18, 2016 at 4:11:49 PM UTC+12, Gregory Ewing wrote:
> The term "automation" is frequently used in the Windows world to mean

> programming something that you would otherwise do manually through a GUI...

Which is not something that GUIs are designed for. Therefore it is at best an unreliable exercise, at worst futile.

[Steven D'Aprano]

Cheese is not designed to be grated and put on spaghetti. Therefore grating
cheese is at best an unreliable exercise, at worst futile.

Can you see the fallacy in your assertion yet? Do I have to spell it out for
you?

In any case, there are many software applications for automating GUI apps.
Contrary to your assertion, it works reliably.

https://duckduckgo.com/?q=gui+automation&ia=web

It would be astonishing if it didn't -- after all, GUI apps interact with the
user not by magic, but via an event queue of mouse movements, clicks, key
presses, etc. This queue is entirely under the control of the computer, which
means a program can simulate a user moving the mouse, clicking, pressing keys,
etc. There's no magic here.




--
Steven
git gets easier once you get the basic idea that branches are homeomorphic
endofunctors mapping submanifolds of a Hilbert space.

[Matt Wheeler]

I would recommend having a look at pywinauto
https://github.com/pywinauto/pywinauto

It presents a very nice pythonic interface to Windows and the controls
within them, allowing statements such as (copied from the Readme):

app.UntitledNotepad.MenuSelect("Help->About Notepad")
app.AboutNotepad.OK.Click()
app.UntitledNotepad.Edit.TypeKeys ("pywinauto Works!", with_spaces = True)

(I found it already quite stable when I first used it a couple of years
ago, and looking at the Readme now it's clearly still an active project,
the optional image capture feature using pillow is new)

>

[Paul Rubin]

Lawrence D’Oliveiro <lawren...@gmail.com> writes:
>> The term "automation" is frequently used in the Windows world to mean
>> programming something that you would otherwise do manually through a GUI...
> Which is not something that GUIs are designed for. Therefore it is at
> best an unreliable exercise, at worst futile.

Windows applications often (usually?) provide automation interfaces,
which are what the rest of us would call API's. This has been done in a
lot of ways: OLE and COM objects back in the day, .NET currently, other
things in between. It's not done by screen scraping or anything stupid
like that. It's actually pretty well thought out, though with the usual
layers of Microsoft and OOP bureaucracy around everything.

[Lawrence D’Oliveiro]

On Sunday, September 18, 2016 at 9:25:53 PM UTC+12, Paul Rubin wrote:

None of the different ways of which are either a) compatible or b) widely supported. Particularly not in Java, as the OP was asking.

Like I said, trying to automate a GUI is a waste of time. GUIs are designed for humans, not computers, to use.

That’s why we have command lines and scripting (which are all just programming at different layers, of course). That’s how you automate things, building higher-level abstract machines on top of lower-level ones. GUIs are the end of the abstraction chain: you cannot build anything more on top of them.

[Christian Gollwitzer]

Am 18.09.16 um 12:03 schrieb Lawrence D’Oliveiro:

> Like I said, trying to automate a GUI is a waste of time. GUIs are
> designed for humans, not computers, to use.

You don't always have a choice. Consider batch-processing a number of
images (say, 30,000 movie frames) using a proprietary effect filter
which works on single images only. It might be easier to drive the GUI
than to recreate the commercial algorithm.

> That’s why we have command lines and scripting (which are all just
> programming at different layers, of course). That’s how you automate
> things, building higher-level abstract machines on top of lower-level
> ones. GUIs are the end of the abstraction chain: you cannot build
> anything more on top of them.

Yes, you can. I agree with you that it is a shaky solution, but that
doesn't make it impossible.

Christian

[Lawrence D’Oliveiro]

On Sunday, September 18, 2016 at 10:13:41 PM UTC+12, Christian Gollwitzer wrote:
>
> Am 18.09.16 um 12:03 schrieb Lawrence D’Oliveiro:
>
>> Like I said, trying to automate a GUI is a waste of time. GUIs are
>> designed for humans, not computers, to use.
>
> You don't always have a choice. Consider batch-processing a number of
> images (say, 30,000 movie frames) using a proprietary effect filter
> which works on single images only. It might be easier to drive the GUI
> than to recreate the commercial algorithm.

Considering the power available in Free Software toolkits like ImageMagick, G’MIC and so on, not to mention libraries accessible from Python itself, let me suggest that such proprietary software simply isn’t worth bothering with any more.

> I agree with you that it is a shaky solution, but that
> doesn't make it impossible.

Is it really something you want to entrust mission-critical business functions to?

[Paul Rubin]

Lawrence D’Oliveiro <lawren...@gmail.com> writes:

>> lot of ways: OLE and COM objects back in the day, .NET currently,

> None of the different ways of which are either a) compatible or b)
> widely supported. Particularly not in Java, as the OP was asking.

I'm quite sure there are Java bindings for all those protocols.

> Like I said, trying to automate a GUI is a waste of time. GUIs are
> designed for humans, not computers, to use.

Automation doesn't simulate button presses or anything like that: the
automate objects expose higher level user actions. E.g. the web browser
object has a navigate method and that sort of thing.

The classic automation example is embedding a chunk of an Excel
spreadsheet in the middle of a Word document, so it's displayed with
Word's fonts and formatting, but when you change a number in the
spreadsheet segment, the formulas run and the other numbers change.
What happens there is Word collects the numbers you type, then calls the
Excel automation interfaces to update the relevant spreadsheet cells and
read back new numbers. There are various hacks in KDE, Gnome, etc. to
do similar things under Linux. It's all transparent to the user and
presents useful features.

> GUIs are the end of the abstraction chain: you cannot build anything
> more on top of them.

IMHO you're not contributing useful insights through these incorrect
guesses about how Windows automation works.

[Christian Gollwitzer]

Am 18.09.16 um 12:26 schrieb Lawrence D’Oliveiro:

> On Sunday, September 18, 2016 at 10:13:41 PM UTC+12, Christian
> Gollwitzer wrote:
>>
>> Am 18.09.16 um 12:03 schrieb Lawrence D’Oliveiro:
>>
>>> Like I said, trying to automate a GUI is a waste of time. GUIs
>>> are designed for humans, not computers, to use.
>>
>> You don't always have a choice. Consider batch-processing a number
>> of images (say, 30,000 movie frames) using a proprietary effect
>> filter which works on single images only. It might be easier to
>> drive the GUI than to recreate the commercial algorithm.
>
> Considering the power available in Free Software toolkits like
> ImageMagick, G’MIC and so on, not to mention libraries accessible
> from Python itself, let me suggest that such proprietary software
> simply isn’t worth bothering with any more.

I was expecting that argument. Free software gives you a lot in this
area, but there are commercial signal processing programs with unmatched
quality. Examples:

https://ni.neatvideo.com/
or for audio
http://www.celemony.com/en/melodyne/what-is-melodyne

Their business model relies on (nontrivial) secret algorithms. Even if
the algorithm is published it might be too tedious to reimplement it
from the scientific paper because it takes months of work or resources
you don't have; for instance, this algorithm

http://graphics.cs.cmu.edu/projects/scene-completion/scene-completion.pdf

requires you to have millions of stock photo images, which you are
allowed to use. If you are flickr, getty or Google, you have no problem.
Otherwise it will be hard.

>
>> I agree with you that it is a shaky solution, but that doesn't make
>> it impossible.
>
> Is it really something you want to entrust mission-critical business
> functions to?

As always, it depends. I wouldn't rest my money on a bank account which
is managed by driving Excel via Sikuli. OTOH, I wouldn't want to spend
years of work to recreate NeatImage to denoise the photos of my last
holiday trip. Here, driving the GUI is fine.

Christian

[Steve D'Aprano]

On Sun, 18 Sep 2016 08:42 pm, Paul Rubin wrote:

> Lawrence D’Oliveiro <lawren...@gmail.com> writes:
>>> lot of ways: OLE and COM objects back in the day, .NET currently,
>> None of the different ways of which are either a) compatible or b)
>> widely supported. Particularly not in Java, as the OP was asking.
>
> I'm quite sure there are Java bindings for all those protocols.
>
>> Like I said, trying to automate a GUI is a waste of time. GUIs are
>> designed for humans, not computers, to use.
>
> Automation doesn't simulate button presses or anything like that: the
> automate objects expose higher level user actions. E.g. the web browser
> object has a navigate method and that sort of thing.

Rather than saying that it *doesn't*, it might be better to say that it
doesn't *necessarily* simulate button presses.

The thing about simulating button presses is that:

(1) you can absolutely guarantee that it does exactly the same as what
happens when a user clicks the button, because there's no difference
between a mouseclick event caused by a human clicking the mouse, a
mouseclick event caused by a robot clicking the mouse, and a mouseclick
event generated by software. They're ALL generated by software, and the
application cannot tell them apart.

(2) It works even if the application doesn't offer an OLE, COM or scripting
interface.



--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[Chris Angelico]

On Sun, Sep 18, 2016 at 8:03 PM, Lawrence D’Oliveiro
<lawren...@gmail.com> wrote:
> Like I said, trying to automate a GUI is a waste of time. GUIs are designed for humans, not computers, to use.

Okay, then. Come up with a way to end-to-end-test a GUI application
without some form of GUI automation.

Sometimes, coming up with a more computer-friendly way to do something
fundamentally defeats the purpose.

ChrisA

[Paul Rubin]

Steve D'Aprano <steve+...@pearwood.info> writes:
>> Automation doesn't simulate button presses

> Rather than saying that it *doesn't*, it might be better to say that it
> doesn't *necessarily* simulate button presses.

I'm no Windoze guru but I always understood Automation (sometimes
written with a capital A) to refer to a specific set of interfaces.
I.e. it's not a generic term for driving one program with another. As
with almost everything, there's a wiki article:

https://en.wikipedia.org/wiki/OLE_Automation

> The thing about simulating button presses is that:
> (1) you can absolutely guarantee that it does exactly the same as what

Yes, this is valuable for UI testing and there were/are several testing
systems that work that way. Automation is something different.

[Michael Torrie]

On 09/18/2016 04:03 AM, Lawrence D’Oliveiro wrote:
> Like I said, trying to automate a GUI is a waste of time. GUIs are
> designed for humans, not computers, to use.

Well then we have a huge problem. Especially for users who are
visually-impaired. Fortunately almost all GUIs (Windows, Linux, and Mac)
are automate-able these days and can be interfaced with with screen
readers and scriptable event generators. This is very very common, even
though you seem to think it's not.

One of the most mature tools for driving GUIs (which we used all the
time when doing scripted installs of Windows) was AutoIt. Works pretty
well actually.

> That’s why we have command lines and scripting (which are all just
> programming at different layers, of course). That’s how you automate
> things, building higher-level abstract machines on top of lower-level
> ones. GUIs are the end of the abstraction chain: you cannot build
> anything more on top of them.

What a nice simplistic view of the world you have.

[Lawrence D’Oliveiro]

On Monday, September 19, 2016 at 2:12:14 AM UTC+12, Chris Angelico wrote:

>
> On Sun, Sep 18, 2016 at 8:03 PM, Lawrence D’Oliveiro wrote:
>
>> Like I said, trying to automate a GUI is a waste of time. GUIs are designed
>> for humans, not computers, to use.
>
> Okay, then. Come up with a way to end-to-end-test a GUI application
> without some form of GUI automation.

There isn’t one. Have you noticed GUI apps are particularly buggy?

[Lawrence D’Oliveiro]

On Monday, September 19, 2016 at 8:00:43 AM UTC+12, Michael Torrie wrote:
>
> On 09/18/2016 04:03 AM, Lawrence D’Oliveiro wrote:
>
>> Like I said, trying to automate a GUI is a waste of time. GUIs are
>> designed for humans, not computers, to use.
>
> Well then we have a huge problem. Especially for users who are
> visually-impaired.

I know one blind computer user who is quite capable with the command line, and who has little fondness for GUI apps. You should see how quickly he works...

[Lawrence D’Oliveiro]

On Sunday, September 18, 2016 at 11:02:57 PM UTC+12, Christian Gollwitzer wrote:
>
> Am 18.09.16 um 12:26 schrieb Lawrence D’Oliveiro:
>

>> Considering the power available in Free Software toolkits like
>> ImageMagick, G’MIC and so on, not to mention libraries accessible
>> from Python itself, let me suggest that such proprietary software
>> simply isn’t worth bothering with any more.
>
> I was expecting that argument. Free software gives you a lot in this
> area, but there are commercial signal processing programs with unmatched
> quality. Examples:
>
> https://ni.neatvideo.com/
> or for audio
> http://www.celemony.com/en/melodyne/what-is-melodyne

If these tools are so wonderful, why don’t they offer command-line versions?

I’ll tell you why: because it would likely mean they would sell fewer copies.

Unless they put in a whole bunch of additional restrictions in the EULA, such as
* You can’t run the program via SSH or a PTY, because this would allow
multiple machines to make use of a single copy, which is not allowed.
* Shell scripts are allowed, but any loop invoking the cheaper version of the
tool is only allowed a maximum of 100 iterations. Also you must write the
scripts using csh, not bash.
* Pipes are limited to a maximum transfer of one gigabyte per day.

A CLI gives the user power over the computer. While a GUI is a great way to give the computer, and proprietary software companies, power over the user.

[Ned Batchelder]

On Sunday, September 18, 2016 at 6:45:32 PM UTC-4, Lawrence D’Oliveiro wrote:
> A CLI gives the user power over the computer. While a GUI is a great way to give the computer, and proprietary software companies, power over the user.

This is completely beside the point of the original question.

--Ned.

[Michael Torrie]

On 09/18/2016 02:22 PM, Lawrence D’Oliveiro wrote:
> I know one blind computer user who is quite capable with the command
> line, and who has little fondness for GUI apps. You should see how
> quickly he works...

Good for him. This is very good that there are tools like that that he
and many others can use, including ourselves. There are also good tools
for those that want or need to use MS Windows or GUI applications.

And, to get back on topic, there are good tools for automating testing
and driving of GUI apps. One I've used is AutoIt. There is even a
Python-based one that Matt Wheeler talked about. I suspect it will work
more or less with the Java apps the original poster needs to work with.

[Lawrence D’Oliveiro]

On Monday, September 19, 2016 at 11:32:25 AM UTC+12, Michael Torrie wrote:
> One I've used is AutoIt.

<https://www.autoitscript.com/wiki/FAQ#Why_doesn.27t_my_script_work_on_a_locked_workstation.3F>

Like I said, this kind of thing can never work reliably...

[Christian Gollwitzer]

Am 19.09.16 um 00:45 schrieb Lawrence D’Oliveiro:

> On Sunday, September 18, 2016 at 11:02:57 PM UTC+12, Christian Gollwitzer wrote:
>>
>> Am 18.09.16 um 12:26 schrieb Lawrence D’Oliveiro:
>>
>>> Considering the power available in Free Software toolkits like
>>> ImageMagick, G’MIC and so on, not to mention libraries accessible
>>> from Python itself, let me suggest that such proprietary software
>>> simply isn’t worth bothering with any more.
>>
>> I was expecting that argument. Free software gives you a lot in this
>> area, but there are commercial signal processing programs with unmatched
>> quality. Examples:
>>
>> https://ni.neatvideo.com/
>> or for audio
>> http://www.celemony.com/en/melodyne/what-is-melodyne
>
> If these tools are so wonderful,

They are.

> why don’t they offer command-line versions?
>
> I’ll tell you why: because it would likely mean they would sell fewer copies.

I agree with you.

>

> A CLI gives the user power over the computer. While a GUI is a great
> way to give the computer, and proprietary software companies, power
> over the user.

I mostly agree with you. Doesn't change the fact, that IF you are in the
situation that you have a program without a reasonable command line
interfacem and IF you need to process some data in an automated fashion
which can't be done from the GUI, then there is room for a "GUI
automation" tool or whatever you call it.

Don't get it wrong, we all like free software and sane APIs and a Python
binding to the mowing robot. Still, sometimes you just need to get the
job done and it doesn't matter how.

Christian

[Lawrence D’Oliveiro]

Which is meaningless, as I explained.

[Ned Batchelder]

We get it, you don't like GUIs. The question is clearly not meaningless,
since others are helping with the question.

--Ned.

--Ned.

[meInvent bbird]

Hi Matt Wheeler,

can it contorl Maplesoft's maple which is a java executable file?

[Lawrence D’Oliveiro]

On Sunday, September 18, 2016 at 10:42:16 PM UTC+12, Paul Rubin wrote:
>
> Lawrence D’Oliveiro writes:
>>

> I'm quite sure there are Java bindings for all those protocols.

Are any of these supported by the Java app in question?

Doesn’t seem like it.

>> Like I said, trying to automate a GUI is a waste of time. GUIs are
>> designed for humans, not computers, to use.
>
> Automation doesn't simulate button presses or anything like that: the
> automate objects expose higher level user actions. E.g. the web browser
> object has a navigate method and that sort of thing.

In other words, the GUI becomes less and less relevant to this use case.

> The classic automation example is embedding a chunk of an Excel
> spreadsheet in the middle of a Word document, so it's displayed with
> Word's fonts and formatting, but when you change a number in the
> spreadsheet segment, the formulas run and the other numbers change.
> What happens there is Word collects the numbers you type, then calls the
> Excel automation interfaces to update the relevant spreadsheet cells and
> read back new numbers. There are various hacks in KDE, Gnome, etc. to
> do similar things under Linux. It's all transparent to the user and
> presents useful features.

That’s not “automation”, that’s “compound documents”. For some reason this facility gets very little use these days.

>> GUIs are the end of the abstraction chain: you cannot build anything
>> more on top of them.
>
> IMHO you're not contributing useful insights through these incorrect
> guesses about how Windows automation works.

Has anybody contributed a non-problematic solution yet?

Precisely.

[Lawrence D’Oliveiro]

On Tuesday, September 20, 2016 at 1:11:20 PM UTC+12, Ned Batchelder wrote:
> We get it, you don't like GUIs.

Who says I don’t like GUIs <http://ldo17.tumblr.com/post/104365910477/cli-versus-gui-deathmatch>?

I just assume we’ve moved on from the 1990s, when they were considered to be the pinnacle of computing evolution, that’s all.

[Matt Wheeler]

On Tue, 20 Sep 2016, 02:47 meInvent bbird, <jobma...@gmail.com> wrote:

> can it contorl Maplesoft's maple which is a java executable file?
>

I don't know maple so I can't answer that.

Which programming language an application is written in isn't really
relevant for pywinauto, it's the graphical toolkit in use which will make a
difference.
>From the one screenshot I found during a quick look at the Maplesoft site,
it looks like maple is using a toolkit which presents native Win32 GUI API
controls, so my *guess* is that it will work, but you'll have to try it to
find out.

I would suggest installing pywinauto and importing it in an interactive
python shell...

>>> import pywinauto
>>> maple = pywinauto.application.Application().start('maple')
>>> maple.Maple.PrintControlIdentifiers()

This will output every control on the window named "Maple" which belongs to
the 'maple' executable which was launched in the step before.
If it outputs lots of stuff you're in luck, you now get to dig through that
output to find the controls you're interested in :)

>

[Emile]

Hmm, then I'll have to wait longer to experience the unreliability as
the handful of automated gui tools I'm running has only been up 10 to 12
years or so.

Emile

[Lawrence D’Oliveiro]

On Thursday, September 22, 2016 at 8:34:20 AM UTC+12, Emile wrote:
> Hmm, then I'll have to wait longer to experience the unreliability as
> the handful of automated gui tools I'm running has only been up 10 to 12
> years or so.

You sound like you have a solution for the OP, then.

[Lawrence D’Oliveiro]

On Monday, September 19, 2016 at 6:47:27 PM UTC+12, Christian Gollwitzer wrote:
> Still, sometimes you just need to get the job done and it doesn't matter how.

That is why the situation continues; because you keep showing a willingness to put up with it.

[Emile van Sebille]

My solution was to automate one of the then available windows gui
scripting tools. I've stopped doing windows in the meantime and no
longer know what's available. My point was that it is possible to
automate windows reliably as long as the programming is robust. You
indicated you found automating unreliable -- I disagree.

Emile

[Lawrence D’Oliveiro]

On Thursday, September 29, 2016 at 4:57:10 AM UTC+13, Emile van Sebille wrote:
> My point was that it is possible to automate windows reliably as long as the
> programming is robust.

Sounds like circular reasoning.

[Emile van Sebille]

Which worked for me! You should try it. Sloppy programming has always
been unreliable.

Emile

[Lawrence D’Oliveiro]

On Thursday, September 29, 2016 at 11:54:46 AM UTC+13, Emile van Sebille wrote:
> Which worked for me! You should try it. Sloppy programming has always
> been unreliable.

So it is clear you don’t have an answer to the OP’s question after all. Just some vague, meaningless generalities.

[Ned Batchelder]

This is just getting rude. Let's please drop it.

--Ned.

[Lawrence D’Oliveiro]

On Thursday, September 29, 2016 at 11:46:59 PM UTC+13, Ned Batchelder wrote:
> This is just getting rude. Let's please drop it.

Do you have anything substantive to contribute?

























(... crickets ...)

[bream...@gmail.com]

This is quite good https://www.youtube.com/watch?v=EnSu9hHGq5o

Certainly better than some crap I've seen, like:-

return \
something

Whoever uses such an appalling style clearly knows nothing about the Python culture.

[Chris Angelico]

Yes. He contributed the guiding hand of "please keep it polite". If
you don't think that's substantive, go have a look at a completely
unmoderated discussion group, then at a well-led community, and see
how much more pleasant it is in one than the other.

Please don't be unnecessarily rude to people. Arguing back and forth
"Windows is terrible", "But I have tools that work just fine on
Windows", "GUIs suck", "No they don't", "You can't automate stuff on
Windows", "Yes you can", etc, etc, is not going to get anyone
anywhere, and it just makes everything unpleasant.

Thanks.

ChrisA

[Steve D'Aprano]

Infinitely more than you.

*plonk*



--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[Michael Torrie]

He's already contributed far more to this list, and to Python, than you
have, and he has for years.

You apparently have nothing constructive to contribute to this topic yet
you can't resist posting and criticizing when people who might have some
small contribution try to post.

As much as I hate to say it, plonk.

[Lawrence D’Oliveiro]

> [irrelevant red-herring rant deleted]

To get things back on track:

OP: How do I automate a GUI app?

Me: It cannot be done reliably in general, and here’s why...

Everybody else: You can’t say that ... waffle-waffle ... try this, or maybe try that ... waffle-waffle ... something worked for me once, but I can’t remember what ... waffle-waffle, huff-and-puff ...

Note to anybody else who wants to post: do you have any advance on “waffle-waffle, huff-and-puff”, or are you just here to lower the signal-to-noise ratio even further?