Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98951 > unrolled thread

non-blocking getkey?

Back to article view | Back to comp.lang.python

Contents

  non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 08:39 +0000
    Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-11-18 10:14 +0100
      Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 10:39 +0000
        Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 11:01 +0000
          Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-11-18 12:17 +0100
          Re: non-blocking getkey? Terry Reedy <tjreedy@udel.edu> - 2015-11-18 07:26 -0500
            Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:06 +0000
              Re: non-blocking getkey? Chris Angelico <rosuav@gmail.com> - 2015-11-19 00:24 +1100
                Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:57 +0000
              Re: non-blocking getkey? Steven D'Aprano <steve@pearwood.info> - 2015-11-19 00:38 +1100
                Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:51 +0000
                  Re: non-blocking getkey? Chris Angelico <rosuav@gmail.com> - 2015-11-19 01:01 +1100
                  Re: non-blocking getkey? Jussi Piitulainen <harvesting@makes.invalid> - 2015-11-18 16:13 +0200
          Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 16:50 +0000
            Re: non-blocking getkey? Terry Reedy <tjreedy@udel.edu> - 2015-11-18 12:55 -0500
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-19 15:48 +0000
                Re: non-blocking getkey? Michael Torrie <torriem@gmail.com> - 2015-11-19 09:31 -0700
                Re: non-blocking getkey? eryksun <eryksun@gmail.com> - 2015-11-20 02:43 -0600
                  Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-23 17:01 +0000
                    askopenfilename() (was: Re: non-blocking getkey?) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 10:29 +0000
                      Re: askopenfilename() Christian Gollwitzer <auriocus@gmx.de> - 2015-11-28 12:45 +0100
                        Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 12:48 +0000
                          Re: askopenfilename() Christian Gollwitzer <auriocus@gmx.de> - 2015-11-28 14:34 +0100
                            Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 16:45 +0000
                          Re: askopenfilename() Laura Creighton <lac@openend.se> - 2015-11-28 17:02 +0100
                      Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 16:05 +0000
          Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 08:28 +0000
            Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-12-10 09:54 +0100
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 10:26 +0000
            Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-12-10 09:57 +0100
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 10:40 +0000
            Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 15:52 +0000
      Re: non-blocking getkey? eryksun <eryksun@gmail.com> - 2015-11-18 12:24 -0600

Page 1 of 2  [1] 2  Next page →

#98951 — non-blocking getkey?

In my program (for python 2.7) the user must enter file names with
mouse copy+paste. I use:

while True:
  file = raw_input(prompt)
  if file == '': break
  files.append(file)
      
The problem now is: my users do not hit ENTER after pasting.
The file names are pasted together in one single line without space or
other delimiter.

My idea now is: instead of raw_input() I use a get_paste() function, which
reads input character for input character and after a (say) 1 s timeout it
returns the string. Pasting a string with the mouse is rather fast, there
should be no big delay between the characters.

How can I implement such a get_paste() function?
I need a non-blocking getkey() function.

It must work on Windows and Linux.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [next] | [standalone]

#98953

Am 18.11.15 um 09:39 schrieb Ulli Horlacher:
> In my program (for python 2.7) the user must enter file names with
> mouse copy+paste. I use:
>
> while True:
>    file = raw_input(prompt)
>    if file == '': break
>    files.append(file)
>
> How can I implement such a get_paste() function?
> I need a non-blocking getkey() function.
> It must work on Windows and Linux.

Non-blocking I/O from the commandline is OS specific. There are 
different solutions, and it's usually hacky (stty on Linux, Console API 
on Windows)

Why do you not use a proper GUI toolkit to do this? It is 
straight-forward to accept keystrokes, copy/paste and drag'n'drop with 
most toolkits. Especially if you target Windows users, I think they 
would be more than happy to get a GUI app then to open a terminal window 
and paste something there. The standard terminal on Windows is very 
ugly, can't resize the width, and pasting works only if you right-click 
-> paste.

	Christian

[toc] | [prev] | [next] | [standalone]

#98957

Christian Gollwitzer <auriocus@gmx.de> wrote:

> > How can I implement such a get_paste() function?
> > I need a non-blocking getkey() function.
> > It must work on Windows and Linux.
> 
> Non-blocking I/O from the commandline is OS specific. There are 
> different solutions, and it's usually hacky (stty on Linux, Console API 
> on Windows)

A "if windows (...) else linux (...)" solution is ok, I have such
distinction already at several places in my code.

Do you have example code for non-blocking I/O?


> Why do you not use a proper GUI toolkit to do this? 

it is too complicated to rewrite my application from CLI to GUI.
But... is there a windows program with which one can select files and the
result is written to STDOUT?
Then I could use pipe open in my Python program.


> The standard terminal on Windows is very ugly, can't resize the width,
> and pasting works only if you right-click -> paste.

You can also use drag&drop. This is ok for my users.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98959

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> it is too complicated to rewrite my application from CLI to GUI.
> But... is there a windows program with which one can select files and the
> result is written to STDOUT?

Found it:

	from Tkinter import Tk
	from tkFileDialog import askopenfilename

	Tk().withdraw()
	file = askopenfilename()


Hey, easy! :-)

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98960

Am 18.11.15 um 12:01 schrieb Ulli Horlacher:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>
>> it is too complicated to rewrite my application from CLI to GUI.
>> But... is there a windows program with which one can select files and the
>> result is written to STDOUT?
>
> Found it:
>
> 	from Tkinter import Tk
> 	from tkFileDialog import askopenfilename
>
> 	Tk().withdraw()
> 	file = askopenfilename()
>
>
> Hey, easy! :-)
>

Welcome to GUI programming ;) Do you still have other data to input? 
There are nice tutorials at http://tkdocs.com and for simple input like 
a single number or a line of text, there is a module simpledialog

	Christian

[toc] | [prev] | [next] | [standalone]

#98962

On 11/18/2015 6:01 AM, Ulli Horlacher wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>
>> it is too complicated to rewrite my application from CLI to GUI.
>> But... is there a windows program with which one can select files and the
>> result is written to STDOUT?
>
> Found it:
>
> 	from Tkinter import Tk
> 	from tkFileDialog import askopenfilename
>
> 	Tk().withdraw()
> 	file = askopenfilename()

To get multiple names, add 's'.  On Windows, one uses control-leftclick 
to get multiple names.  Don't know about other systems.

 >>> fd.askopenfilenames()  # ^click 4 names
('F:/Python/dev/27/Lib/idlelib/aboutDialog.py', 
'F:/Python/dev/27/Lib/idlelib/AutoComplete.py', 
'F:/Python/dev/27/Lib/idlelib/AutoCompleteWindow.pyc', 
'F:/Python/dev/27/Lib/idlelib/Bindings.py')

The limitation is that this will not work if any of the file names 
contain astral (non-BMP) chars because tk cannot handle such characters.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#98966

Terry Reedy <tjreedy@udel.edu> wrote:

> >       from Tkinter import Tk
> >       from tkFileDialog import askopenfilename
> >
> >       Tk().withdraw()
> >       file = askopenfilename()
> 
> To get multiple names, add 's'. 

I have found it already, thanks.


> The limitation is that this will not work if any of the file names 
> contain astral (non-BMP) chars because tk cannot handle such characters.

What are "astral chars"?

But anyway, askopenfilename() is a dead end for me: one cannot select
directories with it, just plain files.
In my application the user MUST select files and directories (in one go).


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98967

On Thu, Nov 19, 2015 at 12:06 AM, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>> The limitation is that this will not work if any of the file names
>> contain astral (non-BMP) chars because tk cannot handle such characters.
>
> What are "astral chars"?

Characters not on the Basic Multilingual Plane (BMP). The Unicode
character set is divided into a number of planes of 65,536 codepoints
each, with the most commonly used ones on the first plane, the BMP. A
lot of programs either cannot use non-BMP characters or have problems
with them; for instance, anything that uses UTF-16 as its internal
representation (ECMAScript, notably; also Python 2 on Windows) sees
astral characters as pairs of code points.

> In my application the user MUST select files and directories (in one go).

It's extremely uncommon to be able to select a combination of files
and directories. The UI for this would be quite annoying, I think. You
may find it easier to have your own wrapper; for example, have a list
of selected files/directories, with buttons "Add File" and "Add
Directory" underneath. The former would use askopenfilenames (despite
the singular in the button name), and the latter would use
askdirectory. Trying to do both at once would be hard.

ChrisA

[toc] | [prev] | [next] | [standalone]

#98973

Chris Angelico <rosuav@gmail.com> wrote:

> > In my application the user MUST select files and directories (in one go).
> 
> It's extremely uncommon to be able to select a combination of files
> and directories. 

I have an uncommon application :-)
Filetransfer of ANY size: http://fex.rus.uni-stuttgart.de:8080/


> The UI for this would be quite annoying, I think. You may find it easier
> to have your own wrapper; for example, have a list of selected
> files/directories, with buttons "Add File" and "Add Directory"
> underneath.

I came (independantly) to the same solution!
So it must be a good idea :-)

http://fex.rus.uni-stuttgart.de:8080/fop/3yxsCacS/X-20151118145221.png


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98970

On Thu, 19 Nov 2015 12:06 am, Ulli Horlacher wrote:

> Terry Reedy <tjreedy@udel.edu> wrote:
> 
>> >       from Tkinter import Tk
>> >       from tkFileDialog import askopenfilename
>> >
>> >       Tk().withdraw()
>> >       file = askopenfilename()
>> 
>> To get multiple names, add 's'.
> 
> I have found it already, thanks.
> 
> 
>> The limitation is that this will not work if any of the file names
>> contain astral (non-BMP) chars because tk cannot handle such characters.
> 
> What are "astral chars"?

Unicode characters beyond U+FFFF.

Unicode covers the entire range of code points (informally characters, don't
worry about the technical difference) from U+0000 to U+10FFFF. The part
following the "U+" is the numeric ordinal value, written in hexadecimal.

Some older versions of Unicode only included 2**16 == 65536 distinct
characters, but many years ago Unicode was extended far beyond that number.
But the first 65536 characters are called the "Basic Multilingual Plane".
All the rest are in the "Supplementary Multilingual Planes", which being a
mouthful to say and write, often gets abbreviated as "astral planes". Hence
the characters themselves are called "astral characters".

Even today, some programming languages and systems have difficulty dealing
with characters that require more than two bytes.

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98972

Steven D'Aprano <steve@pearwood.info> wrote:

> >> The limitation is that this will not work if any of the file names
> >> contain astral (non-BMP) chars because tk cannot handle such characters.
> > 
> > What are "astral chars"?
> 
> Unicode characters beyond U+FFFF.

I see, for very exotic character sets, like Klingon, etc :-)
In my case, I can simple ignore them.


> Unicode covers the entire range of code points (informally characters, don't
> worry about the technical difference) from U+0000 to U+10FFFF. The part
> following the "U+" is the numeric ordinal value, written in hexadecimal.

That was my knowledge so far.


> Some older versions of Unicode only included 2**16 == 65536 distinct
> characters, but many years ago Unicode was extended far beyond that number.
> But the first 65536 characters are called the "Basic Multilingual Plane".
> All the rest are in the "Supplementary Multilingual Planes", which being a
> mouthful to say and write, often gets abbreviated as "astral planes". Hence
> the characters themselves are called "astral characters".

And this was new to me. Learned :-)

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98974

On Thu, Nov 19, 2015 at 12:51 AM, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
> Steven D'Aprano <steve@pearwood.info> wrote:
>
>> >> The limitation is that this will not work if any of the file names
>> >> contain astral (non-BMP) chars because tk cannot handle such characters.
>> >
>> > What are "astral chars"?
>>
>> Unicode characters beyond U+FFFF.
>
> I see, for very exotic character sets, like Klingon, etc :-)
> In my case, I can simple ignore them.

And other exotic character sets, like Chinese.

https://en.wikipedia.org/wiki/CJK_Unified_Ideographs#CJK_Unified_Ideographs_Extension_B

But I'm sure you can ignore them, too. Hardly anyone on this planet
speaks Chinese.

ChrisA

[toc] | [prev] | [next] | [standalone]

#98975

Ulli Horlacher writes:
> Steven D'Aprano wrote:
>
>> >> The limitation is that this will not work if any of the file names
>> >> contain astral (non-BMP) chars because tk cannot handle such
>> >> characters.
>> > 
>> > What are "astral chars"?
>> 
>> Unicode characters beyond U+FFFF.
>
> I see, for very exotic character sets, like Klingon, etc :-)
> In my case, I can simple ignore them.

Better test how your user interface behaves when a user copy-pastes one
of those characters into it. If it merely garbles the character somehow,
you may be able to ignore the problem, but if it promptly shuts down
your whole application and loses some unfinished work, the user may not
be happy.

Klingon may not be that widely spoken, but all manner of little picture
characters seem popular. Wasn't one just chosen to be the Word Of The
Year? And when it's the underlying GUI library that crashes, it's too
late for your program to sanitize the input.

[toc] | [prev] | [next] | [standalone]

#98980

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

>         from Tkinter import Tk
>         from tkFileDialog import askopenfilename
> 
>         Tk().withdraw()
>         file = askopenfilename()

I found another glitch:

After termination of askopenfilename() the window focus is not returned to
the calling window (xterm on Linux, cmd on Windows). I have to click it
again, to regain the focus and continue typing. Is there a workaround?



-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#98989

On 11/18/2015 11:50 AM, Ulli Horlacher wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>
>>          from Tkinter import Tk
>>          from tkFileDialog import askopenfilename
>>
>>          Tk().withdraw()
>>          file = askopenfilename()
>
> I found another glitch:
>
> After termination of askopenfilename() the window focus is not returned to
> the calling window (xterm on Linux, cmd on Windows). I have to click it
> again, to regain the focus and continue typing. Is there a workaround?

What happens with

root = Tk()
root.withdraw()
fiel = ...
root.destroy()

Focus cannot stay with destroyed window.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#99064

Terry Reedy <tjreedy@udel.edu> wrote:
> On 11/18/2015 11:50 AM, Ulli Horlacher wrote:
> > Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> >
> >>          from Tkinter import Tk
> >>          from tkFileDialog import askopenfilename
> >>
> >>          Tk().withdraw()
> >>          file = askopenfilename()
> >
> > I found another glitch:
> >
> > After termination of askopenfilename() the window focus is not returned to
> > the calling window (xterm on Linux, cmd on Windows). I have to click it
> > again, to regain the focus and continue typing. Is there a workaround?
> 
> What happens with
> 
> root = Tk()
> root.withdraw()
> fiel = ...
> root.destroy()
> 
> Focus cannot stay with destroyed window.

The focus is moved to another, unrelated window, but not back to the
window in which the python scripts run. 
Same behaviour on Linux (XFCE) and windows 7.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#99071

On 11/19/2015 08:48 AM, Ulli Horlacher wrote:
> 
> The focus is moved to another, unrelated window, but not back to the
> window in which the python scripts run. 
> Same behaviour on Linux (XFCE) and windows 7.

That's because an app that communicates with standard in and standard
out could be running over telnet, theoretically, so there would be no
window at all. There's absolutely no link in stdin and stdout to a
graphical window.  It's not even possible on Windows as the console
subsystem is completely separate from the GUI subsystem.  When your app
opens a Tk window, it's creating a brand new, top-level window, not
associated with any existing window.

One windows it might be possible to use the win32 api to enumerate the
windows, find your console window and switch to it.   Might even be
possible on Linux using raw X11 calls.

[toc] | [prev] | [next] | [standalone]

#99133

On Thu, Nov 19, 2015 at 10:31 AM, Michael Torrie <torriem@gmail.com> wrote:
> One windows it might be possible to use the win32 api to enumerate the
> windows, find your console window and switch to it.

You can call GetConsoleWindow [1] and then SetForegroundWindow [2].

    import os
    import sys

    try:
        import tkinter
        from tkinter import filedialog
    except ImportError:
        import Tkinter as tkinter
        import tkFileDialog as filedialog
        input = raw_input

    if sys.platform == 'win32':
        import ctypes

        kernel32 = ctypes.WinDLL('kernel32')
        user32 = ctypes.WinDLL('user32')

        def setfgwin():
            hcon = kernel32.GetConsoleWindow()
            if hcon and user32.SetForegroundWindow(hcon):
                return True
            return False

    def get_filename():
        filename = filedialog.askopenfilename()
        setfgwin()
        return os.path.normpath(filename)

    if __name__ == '__main__':
        root = tkinter.Tk()
        root.withdraw()
        filename = get_filename()
        print('filename: %s' % filename)
        input('press enter...')

[1]: https://msdn.microsoft.com/en-us/library/ms683175
[2]: https://msdn.microsoft.com/en-us/library/ms633539

[toc] | [prev] | [next] | [standalone]

#99275

eryksun <eryksun@gmail.com> wrote:
> On Thu, Nov 19, 2015 at 10:31 AM, Michael Torrie <torriem@gmail.com> wrote:
> > One windows it might be possible to use the win32 api to enumerate the
> > windows, find your console window and switch to it.
> 
> You can call GetConsoleWindow [1] and then SetForegroundWindow [2].
(...)

Sorry, for the late feedback: 
great, this works! Thanks!
 

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#99657 — askopenfilename() (was: Re: non-blocking getkey?)

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> eryksun <eryksun@gmail.com> wrote:
> > On Thu, Nov 19, 2015 at 10:31 AM, Michael Torrie <torriem@gmail.com> wrote:
> > > One windows it might be possible to use the win32 api to enumerate the
> > > windows, find your console window and switch to it.
> > 
> > You can call GetConsoleWindow [1] and then SetForegroundWindow [2].
> (...)
> 
> great, this works! Thanks!

One of my Windows test users reports, that the file dialog window of
askopenfilename() starts behind the console window and has no focus.
On Linux (XFCE) I do not have this problem.

I start it with:

  Tk().withdraw()
  file = askopenfilename(title='select a file',initialdir=HOME)
  set_window_focus() # give focus back to console window

Can one force askopenfilename() to start in foreground with focus?

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web