A real newbie question here.
I'm using IDLE 2.7.2 on OSX 10.7.2 and reading Zelle's Python:Programming. I haven't programmed since the 80's, so after going through the command line stuff, I'm excited to dive into Objects. I grab his graphics.py file and copy it into documents (this seems like the default location for IDLE) and start up IDLE.
He then suggests a few commands into the shell:
from graphics import *
win = GraphWin() #which opens a graphics window with no problem
He then goes on to have you draw some lines and shapes in the window. Those graphics show up just fine in the window.
Here's my problem. If I try to mouse over the graphics window, I get the Mac pinwheel. Moving the window doesn't help. So the window seems like it's crashing (though IDLE is doing fine), but strangely, if I keep entering commands into IDLE, the shapes keep drawing normally in the window.
Am I doing something wrong? Is this normal? Thanks,
Henry
Idle runs the python commands you enter in another process, so it's reasonable to expect this "lock up" behavior to be different between the program controlled window and Idle.
What's probably going on, though is that everything is fine, but you have not yet started the event loop in the program you're typing in. The operating system notices that the program is not emptying out its event queue when you mouse over it (which creates lots of events) and it's helpfully informing you (by way of the pinwheel) that the program seems to be busy.
You will likely reach a point later in the tutorial where you do start the event loop, and the pinwheel will magically go away.
Related
I am searching for a way to close a specific window of a program immediately after it opens. Specifically, I am using the BUFF addon for Overwolf and after every game I play, this annoying overlay window opens up and blocks part of my screen. To close it windows Alt+Tab'ing out, I need to wait 10 seconds (that means if I'm not willing to subscribe to BUFF premium), and Alt+Tab'ing out after every game is just as annoying.
Is there any way that I can run a Python script while I'm playing that closes this window every time it opens immediately? I'm thinking of something that continously searches for a window with a specific name or maybe something that listens for the event of a window opening and then checking its name/title. I don't even know if Python can access these processes, but I guess it's worth to just ask.
And before I need to edit the post, I'm using Windows 11.
I am using a code designed by another person in MAC OS. I am using Windows instead and have slightly modified it, but the problem comes when using the GUI that is created.
I have already dealt with a similar issue with a slider. Once I pressed the slider, I couldn´t release it or press another button. I was forced to quit the GUI and start again. I solved it by changing the event command from EVT_COMMAND_SCROLL to EVT_COMMAND_SCROLL_THUMBTRACK. However I did not understand why it worked in MAC OS and does not work in Windows.
Now, I want to close the GUI with the typical cross inside the red button in the right corner of the window. I can do it if it is the first order I do in the GUI. If I first press any button or slider, the exit button does not work.
It made me consider if a major problem is hidden in the code which I am not seeing. I am new at wxPython, which is the module used in the code.
I just ask for your opinion and hope it is a basic error.
Thanks very much
I'm learning python and playing with the subprocess module. After reading several different tutorials and descriptions of how to use the module, my understanding was still not incredibly solid so I started working up some simple code to test the various functions and see how everything worked.
I wanted to see how it might behave if I tried to start the same process multiple times, using this code:
import subprocess
def tpltest(x):
while x > 0:
try:
subprocess.Popen('wordgrinder')
except:
print 'something broke!'
x -= 1
x = raw_input('how many?')
tpltest(x)
When I ran this in my terminal, wordgrinder (terminal word processor) opened normally, but then the cursor advanced down the screen at a rate of about one line per second. It appeared to be movement only, rather than any characters being added to the blank file onscreen. I pressed ctrl+c to see if a wordgrinder remained after closing the first instance and was met with my regular command line prompt, but the cursor continued to scroll. I ran top and did not see extra wordgrinder instances open, but the cursor continued scrolling.
Then I discovered the oddest part. If I rolled my mouse scroll wheel up in the window, chunks of text appeared over the window's contents. Some of the chunks were commands I had entered in the console over the past week, some of them were commands I had entered in my python shell but not the regular terminal, and some of the text was my WiFi security information, including the plaintext WPA2 password for my network. Scrolling the mousewheel down had no effect but scrolling up would overwrite a few lines with new text, seemingly from other random places in my system. After closing the terminal window and opening a new one, things were back to normal.
I'm running Debian 8 64bit with XFCE and using the default terminal emulator.
What did my code do, and why?
The explanation that I can offer is that what subprocess does is to run a background process. Additionally, wordgrinder is a program that takes full control of the terminal session by capturing input from the keyboard (stdin) and controlling the command-line (stdout) in a very particular way.
When you ran wordgrinder in the background through your script, it caused some funky things to happen. That's pretty crazy that your WiFi password ended up getting displayed from your experiment.
Setup: iTerm2 in Mac OS X with a python 2.7 application using curses. Leaving it alone works fine; it uses a timer to update information and rewrite the screen and two pads. If I accidentally "scroll up" with the mousewheel or mousepad, I see the individual "frames" written by iterations in the program's while-loop. Also, this causes some kind of memory or CPU lag such that it takes a VERY long time to get back to the bottom and view the actual application again.
If at all possible, I'd like to avoid this. Any thoughts?
I've done a reasonable amount of coding with the libtcod library, both the C# and python wrappers. My current setup is KUbuntu 14.10, python 2.7.8, and libtcod 1.5.2.
I've made a few programs that work fine, but the latest I've just started doesn't seem to want to allow me to close the console window.
I can send a CTRL+C from the console that I run the program from, and it will close, but, no amount of clicking on the window's "x" button, or Alt+F4s seem to work.
My code is as follows:
'''
justclose.py
'''
import sys
import time
import libtcodpy as libtcod
libtcod.console_set_custom_font(b'lucida12x12_gs_tc.png', libtcod.FONT_TYPE_GREYSCALE | libtcod.FONT_LAYOUT_TCOD)
libtcod.console_init_root(50,50, "The ever-present window", False)
libtcod.console_flush()
while not libtcod.console_is_window_closed():
time.sleep(1)
sys.exit
When I run the program, the console comes up, as expected, and sits around waiting for console_is_window_closed to return true, which it never does. I'm not sure where the problem lies. I can run other programs that use the same initialisation code, and same while loop and which respond just fine to me clicking the close button on the console window.
I've tried looking through an strace of the process, but, I'm not sure I'm up to the task of deciphering it. Nothing looked immediately out of the ordinary.
I'd like some advice on how to track down what's going wrong. Thanks.
EDIT: specifically, I'd like to know how I can check that the close window event is propagating at all, and if so, how far, where it's getting trapped/ignored, that sort of thing. When I run through strace, I see absolutely nothing happening when I click the close button. Is there some better way to debug this?
Replace time.sleep(1) with libtcod.console_check_for_keypress(). When the program sleeps 1 millisecond for each iteration, the program can not respond when you press X. It exits when you press CTRL+C because the program receives the SIGINT signal and it exits immediately. Replacing time.sleep(1) with libtcod.console_check_for_keypress() makes the program check the key pressed on the keyboard, if there is one. That way, the program doesn't block the execution.