![]() This thread automatically starts when instantiated. Method 3 creates an instance of threading.Thread and the wx application is initialized within the run statement. I found that any use of wx.Timer causes this method to fail. This method actually works here but will give errors for a more complex example. Method 2 is a quick attempt to run the main loop on a thread so that the vidSeq function can be called from the main script instead. Essentially, the vidSeq function is passed as an argument to the application that then calls it. The function vidSeq is a video sequencer that gets called on its own thread before the main loop is started. Method 1 allows the main loop to be run as the main thread. The image viewer is periodically updated with images. The purpose of the code is to show an example of a simple image viewer. The code below gives examples of running separate threads. I found that a sleep statement can resolve this but the threading.Lock is more robust. Otherwise, the attributes that the main script needs to communicate with the GUI may not have been initialized and an error will be given. However, in order to access the attributes of the wx application, I use a threading.Lock to block the main thread until the wx application initializes the variables within the Thread class. The wx application now believes that it runs in the main thread. In order to resolve this, we can use the threading.Tread class to instantiate the wx.App within the definition of the run method of that class. When you instantiate a wx.App() with a frame and then start the main loop on a separate thread, wx may report that the main loop is not run in the main thread. For 2.5 it will be when the wx.App object is created. RobinDunn describes the requirement of the main thread in an email response on the wxPython-users list: wxWindows expects that GUI operations and event dispatching can only take place in the main thread, (because of no thread safty in most GUI libs) and it takes some precautions to ensure that things work this way, and problems will probably happen eventually if the MainLoop thread is different than wxWindows "main thread." Whatever thread is the current one when wxWindows is initialized is what it will consider the "main thread." For wxPython 2.4 that happens when wxPython.wx is inported the first time. I found that doing this was not as easy as it seems. ![]() However, if you really want to interact with the GUI dynamically from your script, you may want to start the GUI on a separate thread and then send events to the window from the main script. You could wrap up the script as a function and then pass the function to the wx application that then starts the script on its own thread. Suppose you want to write a script that starts the wx application and then sends events to the GUI in order to update a window. Many of the tools available in the Threading package, such as Locks, are useful in building these applications. Events are used to communicate with the wx application, for example, to update a windows content. The thread may be started from an event within the wx application or it could be started before app. This keeps the GUI responsive as described in LongRunningTasks. If you have code that must be run on a separate thread from the wx application, you will typically start a new thread to run that code from within the MainLoop of the wx application. The Typical Method to Run Separate Threads ![]() There are several methods within wxPython that check to see that the MainLoop is being run in the main thread. However, there are rare situations where one might want to run the wx application on a separate thread. The MainLoop is usually the main thread of the application.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |