This Problem occurs on the RPi (3B+, Raspbian Buster) only. I run the program on my Mac without any problems.
Short description of my program:
After entering the mainloop, the program enters a second thread with another loop (call it requestloop) when the designated button is pressed. The requestloop can be left by pressing the button again. This requestloop requests a xml table via url every 10 seconds which is then parsed with ElementTree, sorted and displayed in a wx.grid.Grid. I use grid.ForceRefresh to make sure the grid is updated.
I hope the following snippet helps to understand the above:
def on_btnrun(self, event):
global run
if self.btnrun.Label == "Start":
run = True
thrupt = threading.Thread(target=self.thrupdate)
thrupt.start()
self.btnrun.SetLabel("Ende")
elif self.btnrun.Label == "Ende":
run = False
self.btnrun.SetLabel("Start")
def thrupdate(self):
while run is True:
reset()
self.grid.ClearGrid()
update(self.grid)
self.grid.ForceRefresh()
time.sleep(10)
Problem:
Now as mentioned in the title the whole wx Window freezes after passing the requestloop between roughly 5 and 20 times. This happens completely randomly, I could not find any regularities. The program keeps running though, for it still prints the output in the terminal every cycle (I added this function for testing).
When I now open another window (eg. menu dropwdown) which lays over the wx Window it will be copied onto the wx Window and stay there after I closed it.
Here are some Images to better understand what I mean (ignore all other widgets that I didn't mention, they are just nonfunctional placeholders).
Image of the wx Window before it freezes
Image of the wx Window after it freezes
Image of the wx Window after opening and closing the dropdown menu
Extra-Info: while building wxPython on the RPi I got some warnings and everytime I run the program I get the following one (it says the actual time instead of time):
(program.py:1666): Gtk-Critical **: time: gtk_distribute_natural_allocation: assertion ‚extra_space >= 0‘ failed
Question:
I have no idea why any of this happens. Is wxPython not stable on Raspbian? Or did the build partly fail? Or is the RPi not having enough rendering capacity?
Solved it by using wx.CallAfter in the details of the update() method.
Related
I'm in a project in which I have to run an Anylogic simulator multiple times. I made an script to modify the input data, run the simulator and then store the output data just before the next simulation run.
The idea is to externally run the simulation (from a python file). The problem is that, when the simulation ends, the simulation window doesn't close automatically so the python file won't continue executing.
I´ve tried to run the simulator without showing the animation of the simulation but still opens a window so it doesn´t work for my purpose.
I don´t know if there is an option in Anylogic to export a model that automatically closes the window once the simulation is completed or if there is any way of creating a simulator that runs without opening any window.
Thank you.
Unfortunately there is no such solution. Even if you can run without UI in Linux, it will not automatically close once the run is complete. I use a workaround:
It is a Python script that scans the outputs folder every 5 seconds and if there are changes in the files, it closes the AnyLogic file. Use this as an inspiration::
from time import sleep
from utils.data.fileSystem import FileSystem
def sync_polling_folder(path, predicate, delay_sec):
print('checking under ' + path + ' folder')
beginning = FileSystem.stat(path)
old = beginning
new = beginning
def two_files_are_different():
return not predicate(str(old), str(new))
def the_process_has_not_begun():
return str(new) == str(beginning) or str(old) == str(beginning)
# if two folders are the same, quit (means no-changes = finished)
# but if they are equal because process never started, keep going
while two_files_are_different() or the_process_has_not_begun():
print('[sleeping] because files are not written yet.')
sleep(delay_sec) # main thread waiting
old = new
new = FileSystem.stat(path)
print('[anylogic] ready to be killed')
return True
after running my simulation model, I have results that are printed on the console. instead of printing on the console, is there a way i can display results on simulation main. i mean once we run the model the simulation window pops up and we push the run button where the simulation main closes and the main window starts running, instead of that once the run button is pushed the simulation main window stays until the simulation is ended and the output is displayed later on simulation main window
Sure. First, untick this box in your sim experiment properties:
Next, drag in a button to your experiment and give it this code:
if ( getState() == IDLE ){
run();
getExperimentHost().setPresentable( this);
}
This starts the model but you stay at the experiment.
To display data, you use the code box below in the experiment using the root keyword to access Main:
NOTE: This only updates after the model run. If you want to see data updates during the run, you need to display it on Main directly (this is what it is for)
I call gtk_window_is_active(wnd) and always receive 0, even when I know for sure that wnd is active and receiving keyboard input. What is the cause and where is the remedy for this?
In fact, I run gtk_window_list_toplevels() and iterate over the list - and gtk_window_is_active() returns 0 for each of them!
When you create a GtkWindow it is still in the 'unrealized' state. You have to call show() on it and let the main loop run, then the window gets realized. So if you call gtk_window_is_active after creating the windows, but before the main loop has chances to run, you will get false.
Thanks to Emmanuele Bassi, Gnome Foundation staff, I figured it out: the problem is that my focus-in-event handler returned 1 (TRUE), and thus prevented the default GTK behaviour. It turned out (something not obvious) that keeping track of the active window is part of that default behavior that i unknowingly overrode.
So, I changed focus-in-event handler of my windows to return FALSE (0), and ever since gtk_window_is_active() works like a clock.
I came to realize an unhelpful (to my task) detail: gtk_window_is_active() only works AFTER all focus-in-event handlers have completed working. Well, I have a mouse click handler that activates some other window, and then needs to check if a certain window is active (these things belong to different objects and different modules, yet are executed within one click hadler invocation). In my case gtk_window_is_active() is useless: it returs FALSE for the active window until after my click handler has finished and the focus-in-handlers (mine and the default) have finished, too.
In my VsCode wxPython application under Windows, I bind the close event to my function as follows:
import wx
class MyFrame(wx.Frame):
def __init__(self, title):
wx.Frame.__init__(self, None, title = title, pos = (150, 0))
self.Bind(wx.EVT_CLOSE, self.OnClose)
# Other stuff ...
def OnClose(self, event):
print("closing")
self.Destroy()
app = wx.App()
top = MyFrame("My App")
top.Show()
app.MainLoop()
print("done")
Now I can see it's being called when I close the top level window (a wxFrame) as the closing and done messages appear. The window itself also disappears.
However VsCode thinks the application is still running since it has the debug controls still available:
and the console that ran it (Python debug console) does not come back with a prompt. It's not until I click on the stop button does the command prompt reappear in that console.
Interestingly, if I run the application outside of VsCode, it exits correctly, returning to the command prompt.
Try wx.Exit() in case you have something still open/running without realising it.
wx.Exit()
Exits application after calling wx.App.OnExit .
Should only be used in an emergency: normally the top-level frame should be deleted (after deleting all other frames) to terminate the application. See wx.CloseEvent and wx.App.
I have a Perl Tk application.
If I move the main window so that it's not right up to the uppermost part of the screen, then the next time the following code is executed, the script fails:
$canvas_fimage_real=$canvas_fimage->Subwidget('canvas');
$canvas_fimage_real=$canvas_fimage unless $canvas_fimage_real;
my $canvas_id=$canvas_fimage_real->id;
my $canvas_fimage_photo=$main_window::main_window->Photo(-format=>'Window', -data=>oct $canvas_id );
And it fails with the following error message:
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 2796
Current serial number in output stream: 2796
The script crashes at the Photo command.
How can I fix this?
Is this a window that is wholly on the screen? The snapshotting facility only works with what is visible on-screen (a low-level X11 condition; not negotiable). As such, you should file a bug report as the snapshot code shouldn't ask for things that it can't get.
Of course, if the window is fully on screen and you're getting that error message anyway, that's a serious problem. File a bug report in that case too!