Hi, I want to use wxPython as the GUI to pretty printer debug information when debugging with GDB.
Since GDB is a console application, I try to avoid blocking the GDB’s command line by running wxPython totally in a separate thread, there is the code:
import wx
import ctypes
from threading import Thread
class Main(Thread):
def init(self):
Thread.init(self)
def run(self):
self.app = wx.App()
f = wx.Frame(None)
# the following code is work around an issue that if the process is hidden, the window won't show up
# see: https://groups.google.com/forum/#!topic/wxpython-users/zmPzeprFKf0
whnd = f.GetHandle()
# SW_SHOW = 5, so we force to set on the WS_VISIBLE window style, see below as a reference
# Window Styles (Windows) - http://msdn.microsoft.com/en-us/library/windows/desktop/ms632600(v=vs.85).aspx
# ShowWindow function (Windows) - http://msdn.microsoft.com/en-us/library/windows/desktop/ms633548(v=vs.85).aspx
ctypes.windll.user32.ShowWindow(whnd, 5)
f.Show()
self.app.MainLoop()
t = Main()
t.start() Enter code here…
``
Here, the GUI creation and app.MainLoop is totally put in a thread, so save the above code to a “test.py” file, then I type the command “source test.py” in the GDB’s command line, a wx.Frame will show correctly. And I can still enter and run GDB command interactively.
I can close the Frame, and the problem happens if I try to exit GDB, there will be a alert message.
See screen shot: http://i683.photobucket.com/albums/vv194/ollydbg_cb/debugalert_zpsd0db6e4b.png
It just said that the function wxSocketBase::IsInitialized`` can only be called in the main thread.
We can see this message comes from the source code here:
https://github.com/wxWidgets/wxWidgets/blob/master/src/common/socket.cpp
bool wxSocketBase::IsInitialized()
{
wxASSERT_MSG( wxIsMainThread(), "unsafe to call from other threads" );
return gs_socketInitCount != 0;
}
``
So, my question is:
How to let this alert message go to console (like stderr)? Jumpping a message box is a bit annoying.
BTW: I think running all the GUI stuff totally in a single thread is safe, right?
Thanks.
asmwarrior(ollydbg)
Hi,
Hi, I want to use wxPython as the GUI to pretty printer debug
information when debugging with GDB.
Since GDB is a console application, I try to avoid blocking the GDB’s
command line by running wxPython totally in a separate thread, there
is the code:
Can’t help with your problem, but wonder if this might help:
http://wiki.wxpython.org/Debugging%20wxWidgets%20From%20wxPython
Werner
Hi, Werner, thanks for the help. After reading the page you pointed, I think this is not related to my original question. In-fact, I just want to use wxPython in GDB’s pretty printer, and visualize some internally data. (normally, gdb just print data in the console), Here is an example about how this works, see: Analyzing C/C++ matrix in the gdb debugger with Python and Numpy- CodeProject
The issue is that as said in the above link page
Notes on using matplotlib in gdb
Before proceeding, it is worth pointing out that when using either matplotlib.pyplot or matplotlib.pylab inside gdb, the show method has to be called for display a figure. Moreover, gdb will not respond to any command until the figure is close.
So, if I try to use the GUI totally in a separate thread, this way I can still use GDB interactively. I have tried using python’s native GUI (tk), but it looks liks tk can not be used in a separate thread, it will either crash or hang GDB. matplotlib’s default backend is tk, but we can have other backends, so I switch to use wxPython as matplotlib’s backend, so far so good. But the only issue is that wxPython will jump a debug alert when I exit GDB.
···
On Tuesday, July 29, 2014 4:22:05 PM UTC+8, werner wrote:
On 7/29/2014 10:16, asm warrior wrote:
I just add one statement after the line “self.app = wx.App()”
self.app.SetAssertMode(wx.PYAPP_ASSERT_SUPPRESS)Enter code here…
``
From the document http://www.wxpython.org/docs/api/wx.PyApp-class.html#SetAssertMode
this function can suppress all the assert, but in my testing, the annoying debug alert message still pops up.
I also test the wx.PYAPP_ASSERT_LOG, but the problem still exists.
I notices that another function DisableAsserts() maybe can get what I want.
http://wxpython.org/Phoenix/docs/html/functions.html#DisableAsserts
But this function is not belong to any classes, it listed as “build-in” functions, so how to call this function?
You might try running wxPython not in a separate thread, but in a separate process. I am doing this for a busy/progress-bar dialog, since I’m using a COM object that would need ‘marshalled’ to allow it to run in a separate thread. Since the wxPython nor COM object liked running in a thread (or didn’t sound easy to get working), I took the route of just starting up a second wxPython for the dialog, and letting the first GUI be frozen (since the COM object has an operation that blocks and takes a while to complete)
see code here:
···
On Tuesday, July 29, 2014 2:07:33 AM UTC-7, asm warrior wrote:
I notices that another function DisableAsserts() maybe can get what I want.
http://wxpython.org/Phoenix/docs/html/functions.html#DisableAsserts
But this function is not belong to any classes, it listed as “build-in” functions, so how to call this function?
whoops, if you want to run that as a demo, you’ll need this in the same directory:
http://commons.wikimedia.org/wiki/File:Spinning_wheel_throbber.gif
···
On Tuesday, July 29, 2014 11:50:04 AM UTC-7, Nathan McCorkle wrote:
You might try running wxPython not in a separate thread, but in a separate process. I am doing this for a busy/progress-bar dialog, since I’m using a COM object that would need ‘marshalled’ to allow it to run in a separate thread. Since the wxPython nor COM object liked running in a thread (or didn’t sound easy to get working), I took the route of just starting up a second wxPython for the dialog, and letting the first GUI be frozen (since the COM object has an operation that blocks and takes a while to complete)
see code here:
http://pastebin.com/ZWKMeABY
On Tuesday, July 29, 2014 2:07:33 AM UTC-7, asm warrior wrote:
I notices that another function DisableAsserts() maybe can get what I want.
http://wxpython.org/Phoenix/docs/html/functions.html#DisableAsserts
But this function is not belong to any classes, it listed as “build-in” functions, so how to call this function?
Hi, Nathan McCorkle, thanks for the help. I just try your sample code, and I found that under Windows, I always see a warning, see the console message when I run your code under GDB. (mp.py contains your source code)
(gdb) source mp.py
E:\code\gdb\mybuild\bin\gdb.exe: unrecognized option --multiprocessing-fork' Use E:\code\gdb\mybuild\bin\gdb.exe --help’ for a complete list of options.
a 5, b a
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
fooNy
calling set event
************trying to refocus modal from parent event
``
When I click on the button, I see the dialog get transparent, and when the work finished, it becomes normal. I’m not sure the full logic of your source code, but I do see you use process here.
···
On Wednesday, July 30, 2014 2:50:41 AM UTC+8, Nathan McCorkle wrote:
whoops, if you want to run that as a demo, you’ll need this in the same directory:
http://commons.wikimedia.org/wiki/File:Spinning_wheel_throbber.gif
On Tuesday, July 29, 2014 11:50:04 AM UTC-7, Nathan McCorkle wrote:
You might try running wxPython not in a separate thread, but in a separate process. I am doing this for a busy/progress-bar dialog, since I’m using a COM object that would need ‘marshalled’ to allow it to run in a separate thread. Since the wxPython nor COM object liked running in a thread (or didn’t sound easy to get working), I took the route of just starting up a second wxPython for the dialog, and letting the first GUI be frozen (since the COM object has an operation that blocks and takes a while to complete)
see code here:
http://pastebin.com/ZWKMeABY
I don’t see any warnings there…
···
On Wednesday, July 30, 2014 7:33:07 AM UTC-7, asm warrior wrote:
On Wednesday, July 30, 2014 2:50:41 AM UTC+8, Nathan McCorkle wrote:
whoops, if you want to run that as a demo, you’ll need this in the same directory:
http://commons.wikimedia.org/wiki/File:Spinning_wheel_throbber.gif
On Tuesday, July 29, 2014 11:50:04 AM UTC-7, Nathan McCorkle wrote:
You might try running wxPython not in a separate thread, but in a separate process. I am doing this for a busy/progress-bar dialog, since I’m using a COM object that would need ‘marshalled’ to allow it to run in a separate thread. Since the wxPython nor COM object liked running in a thread (or didn’t sound easy to get working), I took the route of just starting up a second wxPython for the dialog, and letting the first GUI be frozen (since the COM object has an operation that blocks and takes a while to complete)
see code here:
http://pastebin.com/ZWKMeABY
Hi, Nathan McCorkle, thanks for the help. I just try your sample code, and I found that under Windows, I always see a warning, see the console message when I run your code under GDB. (mp.py contains your source code)
(gdb) source mp.py
E:\code\gdb\mybuild\bin\gdb.exe: unrecognized option --multiprocessing-fork' Use E:\code\gdb\mybuild\bin\gdb.exe --help’ for a complete list of options.
a 5, b a
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
calling updateFunc from faker
fooNy
calling set event
************trying to refocus modal from parent event
``
When I click on the button, I see the dialog get transparent, and when the work finished, it becomes normal. I’m not sure the full logic of your source code, but I do see you use process here.
Which problem? Since I wrote many problem in this thread.
asmwarrior
···
On Saturday, September 26, 2015 at 11:49:53 AM UTC+8, Martin Gregory wrote:
Did you ever solve this?
I have the same problem…
Thanks!
DO NOT CALL MAINLOOP FROM NOT-THE-MAIN-THREAD
···
On 26/09/15 01:20, Martin Gregory
wrote:
Did you ever solve this?
I have the same problem...
Thanks!
–
You received this message because you are subscribed to the Google
Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it,
send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).
The problem of how to run wx.App in a thread without getting that popup.
···
On Saturday, September 26, 2015 at 11:38:43 PM UTC+9:30, asm warrior wrote:
On Saturday, September 26, 2015 at 11:49:53 AM UTC+8, Martin Gregory wrote:
Did you ever solve this?
I have the same problem…
Thanks!
Which problem? Since I wrote many problem in this thread.
OK. Why not?
Does it have to be this way?
I have a simulation process which needs to be extended with a GUI. It seems quite natural to start a thread and put wx in it, updating the GUI with simulation events using CallAfter() from the simulation thread.
It also works absolutely fine, all except for at the end there is this warning dialog upon shutting down.
···
On Sunday, September 27, 2015 at 6:56:14 AM UTC+9:30, Alec Teal wrote:
DO NOT CALL MAINLOOP FROM NOT-THE-MAIN-THREAD
I didn’t realize wx was doing that. There is no reason at all why
MainLoop cannot be called from a secondary thread. The windowing
systems don’t care – all threads are the same. As I’ve said
before, the only restriction is that when you create a window in a
thread, there must be a message loop running in that thread to
handle the messages.
Perhaps the designers were thinking that running MainLoop in a
not-main-thread is usually a programmer error, but if that’s the
case, it’s misguided. That would have to be a relatively uncommon
newbie error, and as you have discovered, it interferes with power
users
···
Martin Gregory wrote:
On Sunday, September 27, 2015 at 6:56:14 AM UTC+9:30, Alec Teal
wrote:
DO NOT CALL MAINLOOP
FROM NOT-THE-MAIN-THREAD
OK. Why not?
Does it have to be this way?
I have a simulation process which needs to be extended with a
GUI. It seems quite natural to start a thread and put wx in
it, updating the GUI with simulation events using CallAfter()
from the simulation thread.
It also works absolutely fine, all except for at the end
there is this warning dialog upon shutting down.
-- Tim Roberts, Providenza & Boekelheide, Inc.
timr@probo.com
I totally agree with Tim's point.
BTW, the annoying message dialog happens in wxWidgets 3.x, and it doesn't happen in wxWidgets(wxPython) 2.8.x
Asmwarrior
···
On 2015-9-29 1:59, Tim Roberts wrote:
I didn't realize wx was doing that. There is no reason at all why MainLoop cannot be called from a secondary thread. The windowing systems don't care -- all threads are the same. As I've said before, the only restriction is that when you create a window in a thread, there must be a message loop running in that thread to handle the messages.
Perhaps the designers were thinking that running MainLoop in a not-main-thread is usually a programmer error, but if that's the case, it's misguided. That would have to be a relatively uncommon newbie error, and as you have discovered, it interferes with power users
