Re: Wait for a keypress before continuing?
John Doe jdoe@usenetlove.invalid wrote: Tim Roberts timr probo.com wrote: That exact code works perfectly for me. The function returns as soon as I press the escape key. You are running this from a console process, and not a GUI process, right? No. I am running this from within Windows, all sorts of Windows. So... Does that mean I will need something complex like a keyboard hook? Or what? I see that this conversation took a nasty turn while I was on vacation. msvcrt.getch works with consoles. If you have an application where stdin and stdout are connected to a real, live console window (which looks just like a command line window), then msvcrt.getch will work. If not, then you have to use the Windows APIs. GetKeyboardState and GetKeyState can tell you if a specific key is currently being pressed. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Aug 17, 3:16 pm, Hans Mulder han...@xs4all.nl wrote: On 17/08/11 10:03:00, peter wrote: Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) The quick and dirty way is to invoke stty(1) using os.system: import os def getpassword(prompt=Password: ): try: os.system(stty -echo) passwd = raw_input(prompt) finally: os.system(stty echo) return passwd Strictly speaking, os.system is deprecated and you should use the equivalent invocation of subprocess.call: import subprocess def getpassword(prompt=Password: ): try: subprocess.call([stty, -echo]) passwd = raw_input(prompt) finally: subprocess.call([stty, echo]) return passwd If you don't want to use an external process, use termios: import termios, sys def getpassword(prompt=Password: ): fd = sys.stdin.fileno() old = termios.tcgetattr(fd) new = termios.tcgetattr(fd) new[3] = new[3] ~termios.ECHO # lflags try: termios.tcsetattr(fd, termios.TCSADRAIN, new) passwd = raw_input(prompt) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old) return passwd These functions work on any Posix system (including Mac OSX), but not on Windows. Hope this helps, -- HansM This is very similar to my solution, which was to use stty turn off keyboard echo, then repeatedly read sys.stdin.read(1) until a unique keystroke had been defined. For example, the 'Insert' key seems to return a sequence of four codes, namely 27, 91, 50, 126. It works but has two disadvantages which I have managed to live with:- 1. As character 27 is used to signal the start of a 'special' key sequence, it cannot detect a single press of the Esc key. The workaround is to detect a double press instead. 2. Some keys seem to return different sets of codes depending on the circumstances. For example, F1 returns 27,91,91,65 from the command line, and 27,79,80 from a GUI window. I suspect there may be variations between flavours of Linux too. The solution is to detect all possibilities - so far I haven't found any overlaps. Not pretty, but as I said it works. I know now not to spend time looking further. Whilst there may be a historical reason for the current situation, it would be a great convenience for amateur coders like mayself if the gurus could devise a platform independent version of mscvrt. If anyone is interested in the code I can post it, but it's quite long as it comprises multiple if statements to cover each combination. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Thu, 18 Aug 2011 01:24:30 -0700, peter wrote: This is very similar to my solution, which was to use stty turn off keyboard echo, then repeatedly read sys.stdin.read(1) until a unique keystroke had been defined. For example, the 'Insert' key seems to return a sequence of four codes, namely 27, 91, 50, 126. It works but has two disadvantages which I have managed to live with:- 1. As character 27 is used to signal the start of a 'special' key sequence, it cannot detect a single press of the Esc key. The workaround is to detect a double press instead. 2. Some keys seem to return different sets of codes depending on the circumstances. For example, F1 returns 27,91,91,65 from the command line, and 27,79,80 from a GUI window. I suspect there may be variations between flavours of Linux too. The solution is to detect all possibilities - so far I haven't found any overlaps. Escape sequences vary between terminals. A given key may have different escape sequences on the Linux console, xterm, a vt220, etc. The termcap and terminfo databases exist for this purpose (terminfo is newer). Some escape sequences vary by mode. E.g. the cursor keys typically produce different sequences depending upon whether the terminal is in keypad mode. The normal solution for distinguishing the escape key from an escape sequence is a timeout. Unfortunately, it needs to be quite long in order to reliably support network (ssh, telnet, etc) connections. Not pretty, but as I said it works. I know now not to spend time looking further. Whilst there may be a historical reason for the current situation, it would be a great convenience for amateur coders like mayself if the gurus could devise a platform independent version of mscvrt. The platform-independent high-level terminal interface is called curses. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, John Doe jdoe@usenetlove.invalid wrote: Context is lost when you quote only one level. Not significantly. I was not answering a question about my code. I was pointing out the fact that my questioner's terminology is strange/corrupt. Well, that's the thing. There was a question there, with perfectly valid terminology. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? Yes, even the common term command line is foreign to me. I do some powerful stuff in Windows, without need for a command line. So apparently you *do* know the term. Normally, to say that a term is foreign to you is to say that you have no idea what it means, not that you know what it means but don't use it. I realize it exists and that some people live by it, but it has been nearly useless to me. In which case, you're not using a command line, and are using a GUI, and the other poster's question is answered. The Google results you cite to are uninteresting and frankly irrelevant. If someone asks me whether the ornamental fish in my 55-gallon tank is a koi, that Google has no hits for ornamental fish in your 55-gallon tank is a koi does not mean that the terminology is strange or corrupt. The terminology was fine. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Wed, Aug 17, 2011 at 7:12 AM, Seebs usenet-nos...@seebs.net wrote: Yes, even the common term command line is foreign to me. I do some powerful stuff in Windows, without need for a command line. So apparently you *do* know the term. Normally, to say that a term is foreign to you is to say that you have no idea what it means, not that you know what it means but don't use it. Unless you're saying it for deliberate effect. Smith: To whom do you pay rent? Arcadian girl: Rent? We do not know what it is to pay rent! Smith: Ah. They're Irish. They know full well what rent means, but don't truly comprehend the concept, as they've never done it. I would say that for many people, command lines are the same thing. For me, photo editing is like that. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Seebs usenet-nospam seebs.net wrote: John Doe jdoe usenetlove.invalid wrote: Context is lost when you quote only one level. Not significantly. Whatever you say, Jeebs. I was not answering a question about my code. I was pointing out the fact that my questioner's terminology is strange/corrupt. Well, that's the thing. There was a question there, with perfectly valid terminology. And I respect your opinion, Jeebs. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? Yes, even the common term command line is foreign to me. I do some powerful stuff in Windows, without need for a command line. So apparently you *do* know the term. Not very well, obviously. Normally, to say that a term is foreign to you is to say that you have no idea what it means, Sounds like being a lexicographer is a fantasy of yours, Jeebs. not that you know what it means but don't use it. But in fact I do not have a clear understanding of what it means, Jeebs, but I know that it's a common term. You are not a lexicographer, dude. I realize it exists and that some people live by it, but it has been nearly useless to me. In which case, you're not using a command line, and are using a GUI, and the other poster's question is answered. That might have been clear to most normal people in my first reply to the first follow-up. I am using Windows XP SP3. Komodo Edit 6 for editing the *.py file. Dragon Naturally Speaking, Natlink, and Dragonfly might all be part of the process. The answer was pointless by the time the question was asked straightforward. Thanks to the prior replies, by then I had already figured out that I need a keyboard hook. The answer doesn't matter anymore. The Google results you cite to are uninteresting and frankly irrelevant. You have every right to an opinion, Fuckturd. If someone asks me whether the ornamental fish in my 55-gallon tank is a koi, that Google has no hits for ornamental fish in your 55-gallon tank is a koi does not mean that the terminology is strange or corrupt. No wonder you don't quote relevant material, Jeebs. If anybody knew what you were comparing that expression to, you would look stupid. The terminology was fine. Are you a master of terminology on wikishit, Jeebs? I think wikishit sucks. Wannabe lexicographers like you might be a reason. I've dealt with some real lexicographers, Jeebs, you aren't one. -- -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. Path: news.astraweb.com!border6.newsrouter.astraweb.com!news.glorb.com!newsfeeds.sol.net!post2.nntp.sol.net!posts.news.megabitz.net!nnrp3-asbnva.megabitz.net!not-for-mail Newsgroups: comp.lang.python From: Seebs usenet-nospam seebs.net Subject: Re: Wait for a keypress before continuing? References: 4e3f2827$0$5826$c3e8da3$12bcf670 news.astraweb.com 4e4ad039$0$9663$c3e8da3$76491128 news.astraweb.com acpl475c1ae1pgcv73hj2oqln7n0qn6tkl 4ax.com 4e4ae844$0$29730$c3e8da3$92d0a893 news.astraweb.com mailman.107.1313539907.27778.python-list python.org 4e4b3b02$0$30718$c3e8da3$f017e9df news.astraweb.com slrnj4mjr1.2pre.usenet-nospam guild.seebs.net 4e4b566c$0$3959$c3e8da3$b23f186d news.astraweb.com User-Agent: slrn/0.9.9p1 (Darwin) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: slrnj4mmtc.2sah.usenet-nospam guild.seebs.net Date: 17 Aug 2011 06:12:02 GMT Lines: 40 Organization: Megabitz - More USENET, Faster USENET NNTP-Posting-Date: 17 Aug 2011 06:12:02 GMT NNTP-Posting-Host: 3c8d6a06.news.megabitz.net X-Trace: DXC=BKlkN0:D\OSc::[BQideGP6FU_Q:4mR^W\Y;gN2lO]C2e6efi]9Z?jW6Mmc0=4W7d DE\31QYU2V739;gZ5P?i9TYFJHfQZUBoD_OMJGJU?7AKaKNWGF_ X-Complaints-To: abuse megabitz.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Wed, 17 Aug 2011 05:23 pm John Doe wrote: You have every right to an opinion, Fuckturd. I shouldn't need to say this to anyone over the age of four, but being obnoxious to people trying to help does not encourage others to answer your question. You don't win points for insulting people who are trying to solve your problems. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Welcome to my killfile. *plonk* -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 17/08/11 10:03:00, peter wrote: Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) The quick and dirty way is to invoke stty(1) using os.system: import os def getpassword(prompt=Password: ): try: os.system(stty -echo) passwd = raw_input(prompt) finally: os.system(stty echo) return passwd Strictly speaking, os.system is deprecated and you should use the equivalent invocation of subprocess.call: import subprocess def getpassword(prompt=Password: ): try: subprocess.call([stty, -echo]) passwd = raw_input(prompt) finally: subprocess.call([stty, echo]) return passwd If you don't want to use an external process, use termios: import termios, sys def getpassword(prompt=Password: ): fd = sys.stdin.fileno() old = termios.tcgetattr(fd) new = termios.tcgetattr(fd) new[3] = new[3] ~termios.ECHO # lflags try: termios.tcsetattr(fd, termios.TCSADRAIN, new) passwd = raw_input(prompt) finally: termios.tcsetattr(fd, termios.TCSADRAIN, old) return passwd These functions work on any Posix system (including Mac OSX), but not on Windows. Hope this helps, -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Hans Mulder wrote: Strictly speaking, os.system is deprecated and you should use the equivalent invocation of subprocess.call: Strictly speaking, os.system is *not* deprecated in either Python 2.x or 3.x. Latest stable documentation for Python 2.7 and 3.2: http://docs.python.org/library/os.html#os.system http://docs.python.org/py3k/library/os.html#os.system And docs in development for 3.3 (unstable): http://docs.python.org/dev/library/os.html#os.system Deprecation means that there are active plans to remove the feature. There are no such plans to remove os.system. What the docs say is much milder: The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. Using subprocess may be recommended, but that is not the same as saying that os.system is deprecated. os.system will not be going away any time in the foreseeable future. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, peter peter.mos...@talk21.com wrote: Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) There's no direct equivalent to the whole of msvcrt. The Unixy way to do stuff like that on the command line is usually curses. But to make a long story short: Unix evolved in a setting where there was often not a user at *THE* console, and users were often on devices such that it made sense to have all the line editing happen on the remote end, with the remote end sending a completed line once the user was done with all that stuff like backspaces. Unix programs that do stuff like this for tty input do exist, of course, but for the most part, they use an entire API designed for creating such utilities, rather than one or two specialized functions. (Another part of the reason for this: The Unix solution scales nicely to the case where the five people using your program will be doing so on physically different hardware terminals which don't use the same escape sequences for cursor movement.) Usually when people omit something obvious from a design, it's because of other constraints or history to the design which make it less obvious. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 8/17/2011 12:33 PM, Seebs wrote: On 2011-08-17, peterpeter.mos...@talk21.com wrote: Is there an equivalent to msvcrt for Linux users? I haven't found one, and have resorted to some very clumsy code which turns off keyboard excho then reads stdin. Seems such an obvious thing to want to do I am surprised there is not a standard library module for it. Or have I missed someting (wouldn't be the first time!) There's no direct equivalent to the whole of msvcrt. The Unixy way to do stuff like that on the command line is usually curses. But to make a long story short: Unix evolved in a setting where there was often not a user at *THE* console, and users were often on devices such that it made sense to have all the line editing happen on the remote end, with the remote end sending a completed line once the user was done with all that stuff like backspaces. Unix programs that do stuff like this for tty input do exist, of course, but for the most part, they use an entire API designed for creating such utilities, rather than one or two specialized functions. (Another part of the reason for this: The Unix solution scales nicely to the case where the five people using your program will be doing so on physically different hardware terminals which don't use the same escape sequences for cursor movement.) The difference is between Hit enter to continue (which we can do in portable Python) versus Hit any key to continue (which we cannot, and which also leads to the joke about people searching for the 'any' key ;-). The equivalent contrast for GUIs is Click OK to continue versus Click anywhere to continue If having to click a specific area is okay for GUIs, having to hit a specific key for TUIs should be also. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I shouldn't need to say this to anyone over the age of four, but being obnoxious to people trying to help does not encourage others to answer your question. You don't win points for insulting people who are trying to solve your problems. The frustrating part, of course, is that the people who do this are doing it for reasons such that the explanation seems only proof that they are even more right than they had previously expected. Pathological narcissism is scary. If you ever find yourself going longer than usual without being wrong, start checking your work more carefully. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, Terry Reedy tjre...@udel.edu wrote: The difference is between Hit enter to continue (which we can do in portable Python) versus Hit any key to continue (which we cannot, and which also leads to the joke about people searching for the 'any' key ;-). And more importantly, frustration and confusion when people pick control or shift. The equivalent contrast for GUIs is Click OK to continue versus Click anywhere to continue If having to click a specific area is okay for GUIs, having to hit a specific key for TUIs should be also. In general I agree. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Seebs wrote: Pathological narcissism is scary. If you ever find yourself going longer than usual without being wrong, start checking your work more carefully. :) +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Terry Reedy wrote: The difference is between Hit enter to continue (which we can do in portable Python) versus Hit any key to continue (which we cannot, and which also leads to the joke about people searching for the 'any' key ;-). The equivalent contrast for GUIs is Click OK to continue versus Click anywhere to continue If having to click a specific area is okay for GUIs, having to hit a specific key for TUIs should be also. Poor analogy. A better analogy to a GUI would be comparing: What would you like to do? Select an option and then click OK: ( ) Cancel ( ) Print (x) Save [__OK__] versus: What would you like to do? [__Cancel__] [__Print__] [__Save__] Actually, a better analogy would be a GUI that made you do this: What would you like to do? Type the first letter of the option you prefer in the text field, then click the OK button: Options: Cancel | Print | Save My option: [ ][__OK__] (ASCII art best viewed with a fixed-width font.) Generally speaking, the second UI would be preferred. The raw_input/input UI is well-designed for entering plain text data. It is extremely poor as a command interface. Bringing it back to text interfaces, it would be useful to have a text interface such that commands can be executed using a single key press. You might want to detect and respond to (say) the arrow keys, or ESC, or P rather than Penter. Curses apps can do it, proof that even under Unix it is desirable. (Imagine how awkward it would be to use a TUI mail client or text editor where the only user input was from something like raw_input.) Unfortunately curses is quite heavyweight for a simple CLI script. I note also that even the Python interactive interpreter under Linux has an extremely limited detect-single-keypress capability: Ctrl-C generates a KeyboardInterrupt without needing to hit Enter, and Ctrl-D exits the interpreter. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Wed, Aug 17, 2011 at 7:29 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The raw_input/input UI is well-designed for entering plain text data. It is extremely poor as a command interface. ... (Imagine how awkward it would be to use a TUI mail client or text editor where the only user input was from something like raw_input.) I run a MUD and play several. MUDs by definition have only line-based input (if you use a raw TELNET client, you have character-based input, but most MUD clients send entire lines of text at once); yet it is possible to implement a reasonably-viable file editor. It's not difficult to become quite proficient with line-based editors, especially if you rig some client-side support (which I have done on two of the MUDs). Line-based input is excellent as a command interface, if commands consist of verbs and parameters. It's terrible for playing Tetris on. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
def wait_for_keystroke(): char=0 while not char==0x1B: char=msvcrt.getch() That freezes the process. Am I using the right code for the escape key, or doing anything else wrong? Again, I know it could be my system. But I must find a way to do this from within Windows. I use a keyboard hook written in C++, maybe something from that would be useful, but maybe complex. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
def wait_for_keystroke(): char=0 while not char==0x1B: char=msvcrt.getch() I tried using while not char==chr(27): -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
def wait_for_keystroke(): char=0 while not (char==chr(27) or char==chr(110)): char=msvcrt.getch() if char==0: return That freezes the process. That means char=msvcrt.getch() is getting something? Could it have something to do with the formatting of the character? -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
John Doe jdoe@usenetlove.invalid wrote: def wait_for_keystroke(): char=0 while not (char==chr(27) or char==chr(110)): char=msvcrt.getch() if char==0: return That freezes the process. That exact code works perfectly for me. The function returns as soon as I press the escape key. You are running this from a console process, and not a GUI process, right? That means char=msvcrt.getch() is getting something? Did you ever think about inserting a debug statement to help you? print hex(ord(char)) -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Tim Roberts timr probo.com wrote: John Doe jdoe@usenetlove.invalid wrote: def wait_for_keystroke(): char=0 while not (char==chr(27) or char==chr(110)): char=msvcrt.getch() if char==0: return That freezes the process. That exact code works perfectly for me. The function returns as soon as I press the escape key. You are running this from a console process, and not a GUI process, right? No. I am running this from within Windows, all sorts of Windows. So... Does that mean I will need something complex like a keyboard hook? Or what? Thanks. -- That means char=msvcrt.getch() is getting something? Did you ever think about inserting a debug statement to help you? print hex(ord(char)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Okay... Looks like I need pyHook. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On Tue, Aug 16, 2011 at 5:59 PM, John Doe jdoe@usenetlove.invalid wrote: No. I am running this from within Windows, all sorts of Windows. What does that mean? You seem very resistant to answering anyone's questions about your code. Is your code run from the command line, or does it have a GUI? If it has a GUI, what windowing toolkit are you using? If you have code that's not working, please, show us a short, run-able bit of sample code that demonstrates the problem you're experiencing. Describe the behavior you see, the behavior you expected instead, and the full text of any traceback you may be getting. -- Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Jerry Hill malaclypse2 gmail.com wrote: John Doe jdoe usenetlove.invalid wrote: No. I am running this from within Windows, all sorts of Windows. What does that mean? You snipped the context, Benny. You seem very resistant to answering anyone's questions about your code. No one else has had a problem with my code, Benny, and you have not questioned my code. I laid it out, they tried it, and now we're getting on with it. Is your code run from the command line, or does it have a GUI? Using does your code have a GUI produces zero search results. Maybe that works better in some other language. If it has a GUI, what windowing toolkit are you using? I guess the answer is Dragonfly. Or maybe it's Komodo (the IDE), as previously stated. I have never been interested in making Windows, just making Windows dance. I do macroing. If you have code that's not working, please, show us a short, run-able bit of sample code that demonstrates the problem you're experiencing. Benny... Apparently you have missed at least two other replies that said they tried some of the code I provided and it worked fine for them. As already stated, a hook is probably required. It's not a big surprise to me, but it's a lot more work. And now I am in the process of getting it done. I expect the results to be very pleasant, though. I'm going to have a system that does voice-activated scripting combined with a systemwide hook, all in one package. If I can get the hook properly installed, it should rock, and I'm ready to tackle it. -- Describe the behavior you see, the behavior you expected instead, and the full text of any traceback you may be getting. -- Jerry Path: news.astraweb.com!border6.newsrouter.astraweb.com!news.glorb.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: malaclypse2 gmail.com X-Original-To: python-list python.org Delivered-To: python-list mail.python.org X-Spam-Status: OK 0.054 X-Spam-Evidence: '*H*': 0.89; '*S*': 0.00; 'sorts': 0.04; 'answering': 0.09; 'demonstrates': 0.09; '16,': 0.15; 'doe': 0.16; 'getting.': 0.16; 'subject:continuing': 0.16; 'wrote:': 0.16; 'header:In- Reply-To:1': 0.22; 'tue,': 0.23; 'pm,': 0.24; 'command': 0.24; 'aug': 0.24; 'traceback': 0.24; 'code': 0.25; 'code.': 0.26; 'bit': 0.28; 'problem': 0.28; 'message-id: mail.gmail.com': 0.29; 'toolkit': 0.30; 'subject:?': 0.31; 'seem': 0.31; 'does': 0.32; 'to:addr:python-list': 0.33; 'describe': 0.34; 'see,': 0.34; 'short,': 0.34; 'running': 0.35; 'instead,': 0.37; 'run': 0.37; 'received:google.com': 0.38; 'received:209.85': 0.38; 'subject:: ': 0.39; 'to:addr:python.org': 0.39; 'your': 0.61; 'john': 0.62; 'full': 0.63; 'show': 0.67; 'received:209.85.215.174': 0.67; 'received:mail-ey0-f174.google.com': 0.67; 'resistant': 0.84; 'windowing': 0.84; 'working,': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=09nEr3tlARCpTiOfhP1XOnteJhDd/baJpJhzNhp5UsI=; b=v9cmI/PvRfaLZhXxYs1bHlUOG+IaGEjPq0Xmx+WTkTOPc5YRFRNivsVO8wgKHaWXZm LhxtRbBJaAJuZlXNZ2rX2BxXaT8VJ6wnn2Z1gRv83Jqxi+jJ4zHcfExLPrLRzxLKZXOc oeVqZwTxJRX8VOytC17/RwVjznYcamlxZsG3Q= MIME-Version: 1.0 In-Reply-To: 4e4ae844$0$29730$c3e8da3$92d0a893 news.astraweb.com References: 4e3f2827$0$5826$c3e8da3$12bcf670 news.astraweb.com 4e4ad039$0$9663$c3e8da3$76491128 news.astraweb.com acpl475c1ae1pgcv73hj2oqln7n0qn6tkl 4ax.com 4e4ae844$0$29730$c3e8da3$92d0a893 news.astraweb.com Date: Tue, 16 Aug 2011 20:11:39 -0400 Subject: Re: Wait for a keypress before continuing? From: Jerry Hill malaclypse2 gmail.com To: python-list python.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: python-list python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language python-list.python.org List-Unsubscribe: http://mail.python.org/mailman/options/python-list, mailto:python-list-request python.org?subject=unsubscribe List-Archive: http://mail.python.org/pipermail/python-list List-Post: mailto:python-list python.org List-Help: mailto:python-list-request python.org?subject=help List-Subscribe: http://mail.python.org/mailman/listinfo/python-list, mailto:python-list-request python.org?subject=subscribe Newsgroups: comp.lang.python Message-ID: mailman.107.1313539907.27778.python-list python.org Lines: 13 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1313539907 news.xs4all.nl 23971 [2001:888:2000:d::a6]:45697 X-Complaints-To: abuse xs4all.nl -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 2011-08-17, John Doe jdoe@usenetlove.invalid wrote: Using does your code have a GUI produces zero search results. Maybe that works better in some other language. You shouldn't need a search engine to answer a question about your code. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Seebs usenet-nospam seebs.net wrote: John Doe jdoe usenetlove.invalid wrote: Using does your code have a GUI produces zero search results. Maybe that works better in some other language. You shouldn't need a search engine to answer a question about your code. Context is lost when you quote only one level. I was not answering a question about my code. I was pointing out the fact that my questioner's terminology is strange/corrupt. If you do, it suggests that perhaps one or more of the terms are unfamiliar to you? Yes, even the common term command line is foreign to me. I do some powerful stuff in Windows, without need for a command line. I realize it exists and that some people live by it, but it has been nearly useless to me. -- -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam seebs.net http://www.seebs.net/log/ -- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) -- get educated! I am not speaking for my employer, although they do rent some of my opinions. Path: news.astraweb.com!border6.newsrouter.astraweb.com!news.glorb.com!news-out.readnews.com!transit3.readnews.com!newspump.sol.net!post2.nntp.sol.net!posts.news.megabitz.net!nnrp2-asbnva.megabitz.net!not-for-mail Newsgroups: comp.lang.python From: Seebs usenet-nospam seebs.net Subject: Re: Wait for a keypress before continuing? References: 4e3f2827$0$5826$c3e8da3$12bcf670 news.astraweb.com 4e4ad039$0$9663$c3e8da3$76491128 news.astraweb.com acpl475c1ae1pgcv73hj2oqln7n0qn6tkl 4ax.com 4e4ae844$0$29730$c3e8da3$92d0a893 news.astraweb.com mailman.107.1313539907.27778.python-list python.org 4e4b3b02$0$30718$c3e8da3$f017e9df news.astraweb.com User-Agent: slrn/0.9.9p1 (Darwin) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: slrnj4mjr1.2pre.usenet-nospam guild.seebs.net Date: 17 Aug 2011 05:06:24 GMT Lines: 14 Organization: Megabitz - More USENET, Faster USENET NNTP-Posting-Date: 17 Aug 2011 05:06:24 GMT NNTP-Posting-Host: 93ee8380.news.megabitz.net X-Trace: DXC=oHM8SW;d^:0L\jMDQ^7Q0;6FU_Q:4m2^W\Y;gN2lO=:j84KQkNLA7b6gdG D9A77d DE\31QY52V739;gZ50?i9TYFJHfQ:dL=K2MaaFN9WbYhm5j?WK1 X-Complaints-To: abuse megabitz.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
On 08/08/2011 04:44 AM, John Doe wrote: Steven D'Aprano steve+comp.lang.python pearwood.info wrote: Also, are you using an IDE? If so, it could very well be interfering with the keyboard buffer I really don't know how to answer your question. I am using Windows XP SP3. Komodo Edit 6 for editing the *.py file. Dragon Naturally Speaking, Natlink, and Dragonfly might all be part of the process. Must be my system. I will post the solution if it comes up. Main question is whether your script is exectued in a console window (like cmd.exe) or from within a graphical library without console. you yould try to start cmd.exe and call your python script directly from there. if this doesn't work, then try just a simple test script containing nothing else than the code to wait for a keypress. Simple test script (working fine for me) import msvcrt print before msvcrt.getch() print after -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
John Doe wrote: My program does not need a prompt, it just needs to wait for any key to be pressed before it continues. This is in Windows. char=0 while not char: char=msvcrt.getch() That doesn't delay anything here. Works perfectly for me. You don't need the while loop, since getch blocks until a key is pressed. Rather than making arbitrary changes to the code, try printing char after the loop exits and see what it contains. That may give you a hint as to what is going on. Also, are you using an IDE? If so, it could very well be interfering with the keyboard buffer, for its own purposes. E.g. in IDLE 2.6.2, if I call getch it *immediately* returns without blocking: msvcrt.getch() '\xff' -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Wait for a keypress before continuing?
Steven D'Aprano steve+comp.lang.python pearwood.info wrote: Also, are you using an IDE? If so, it could very well be interfering with the keyboard buffer I really don't know how to answer your question. I am using Windows XP SP3. Komodo Edit 6 for editing the *.py file. Dragon Naturally Speaking, Natlink, and Dragonfly might all be part of the process. Must be my system. I will post the solution if it comes up. -- http://mail.python.org/mailman/listinfo/python-list
