Correct, however, I couldn't get this to work by playing with the examples.
It certainly became self-evident by simply adding a pyShell to my panel,
cool.
I often add something like this when testing my apps, or the samples that people send to the list to ask for help:
frame = MainFrame(None) # whatever the app's main frame is
frame.Show()
if len(sys.argv) > 1 and sys.argv[1] == '-s':
from wx import py
shell = py.shell.ShellFrame(
frame, locals=dict(wx=wx, frame=frame, app=self))
shell.Show()
frame.Raise()
The key is setting the locals parameter. Whatever you want to have access to in the shell, just give it an entry in the dictionary and it will then be in the initial namespace available when the shell starts up.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
This triggered a thought (warning: fuzzy, unfiltered thoughts ahead): suppose you replaced py.shell in the above with a tool that designed to conduct automated testing of your app? It could read a script that specifies a sequence of events to send (and widgets to send them to) and expressions to evaluate on the results. Has something along this line been done? If not, does it seem feasible? (I can see that there's likely a raft of issues and traps to be dealt with, but I'm just wondering at this point if it's a feasible and tractable approach.)
Right now we're building most of our screens with MVC and use the Python unittest module to test it. I don't know whether it's the right thing to put the testing runner inside the app. I'm using a separate script to run them. On the other hand, if you want to run unit tests in the environment the user has it might be a good idea to pack the testing code with the app.
I wasn't thinking of that so much as the ability to do unit testing of the GUI side of the app. However, I can imagine cases where it's useful to be able tell the user "run with the -s flag and let's see what's happening on the inside".
I know, I've always had that feeling too. But the common wisdom for writing unit tests says that you should rely on as few external components as possible (using some kind of mock framework for instance). And when something goes wrong with your program on a client's station it usually has to do with the environment the program is running in - something not usually tested with unit tests.
I'm not entirely sure how to create a suite of tests that will test the environment you're running in. By definition it is the most unpredictable thing.