I have a simple wxPython application that is behaving strangely. I figured
that a cool way to sort things out would be to bolt on a second window with
PyCrust (& filling) in it. Then I could noodle around, looking at variables,
testing functions and object methods, etc.
Well, I've got the second window (er... frame) working fine, and I have
pyCrust and fillings in there, but I haven't been able to figure out how to
expose the full program state to pyCrust.
If it helps, I'm running python 2.2, wxPython 2.3.3.1 on windows NT4.0 (this
app will end up on Win 2K, NT, XP, maybe even 9x.)
Right now I've got stuff structured like this:
MyApp
contains MyMainFrame
which contains MyPyShellFrame, creating it on _init_ and showing it as
required.
which contains a pyShell and a filling in a splitter window.
I'm able to give pyShell access to the variables, etc. in MyPyShellFrame,
but not to anything further up the hierarchy (where all the interesting data
is.)
Please help!
William.
P.S.
PyCrust is amazingly cool!
P.P.S.
I used wxGlade to lay out my windows. It is also amazingly cool. Much thanks
to those who make these tools possible.
I have a simple wxPython application that is behaving strangely. I figured
that a cool way to sort things out would be to bolt on a second window with
PyCrust (& filling) in it. Then I could noodle around, looking at
variables, testing functions and object methods, etc.
That's the way to do it.
Well, I've got the second window (er... frame) working fine, and I have
pyCrust and fillings in there, but I haven't been able to figure out how to
expose the full program state to pyCrust.
There are actually a could of different ways. I gave some details on this in
my O'Reilly article. See if this helps:
You can also look at some of the techniques I used in PyCrustApp.py:
class App(wxApp):
"""PyCrust standalone application."""
def OnInit(self):
wxInitAllImageHandlers()
locals = {'__app__': 'PyCrust Standalone Application'}
self.crustFrame = CrustFrame(locals=locals)
self.crustFrame.SetSize((750, 525))
self.crustFrame.Show(true)
self.SetTopWindow(self.crustFrame)
# Add the application object to the sys module's namespace.
# This allows a shell user to do:
# >>> import sys
# >>> sys.application.whatever
import sys
sys.application = self
return true
So you could add a reference to your main program object in the locals
dictionary that gets passed to CrustFrame, or attach it to the sys module, or
modify shell.interp.locals directly. Clear as mud?
P.S.
PyCrust is amazingly cool!
Thanks! Glad you like it. BTW, it sounded as though you were putting together
the shell and filling classes along with your own splitter. If so, you might
want look at crust.py where there is a Crust class that does all that for
you. Hope this helped.
···
On Friday 18 October 2002 09:52 am, William Wicker wrote:
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
I've attached a bunch of changes I've made to the ColourSelect buttons, that are distributed with wxPython. Any comments are appreciated. I've only tested this on Windows with wxPython 2.3.3.1 and Python 2.2 (but am not using any 2.2 additions).
1) Fixed bug: The color dialog did not save the custom colors from one invocation to the next.
2) I created a new widget, "ColorWell". This is meant to look like the color wells in the Windows color chooser and some graphics software. I think that this is a more standard UI/view for this kind of functionality.
3) I separated the logic of using the color dialog from the GUI widget so that new widgets could be easily extended with color setting/editing ability (like I did with wxPanel).
I've attached a bunch of changes I've made to the ColourSelect buttons, that are distributed with wxPython. Any comments are appreciated. I've only tested this on Windows with wxPython 2.3.3.1 and Python 2.2 (but am not using any 2.2 additions).
1) Fixed bug: The color dialog did not save the custom colors from one invocation to the next.
2) I created a new widget, "ColorWell". This is meant to look like the color wells in the Windows color chooser and some graphics software. I think that this is a more standard UI/view for this kind of functionality.
3) I separated the logic of using the color dialog from the GUI widget so that new widgets could be easily extended with color setting/editing ability (like I did with wxPanel).
Nice. Especially the ColourWell as you may or may not be able to set button colours on non-MSW platforms.
If you want to make it backwards compatible with ColourSelect, and send it as a patch to colourselect.py then I'll apply it.
It would also be nice if it was easy to share the wxColourData across different ColourWells and/or ColourSelects, so the custom colours can be saved and reset when the app is run again.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
...send a patch to colourselect.py then I'll apply it.
...It would also be nice if it was easy to share the wxColourData across different ColourWells and/or ColourSelects, so the custom colours can be saved and reset when the app is run again.
Yep! I had this same thought, and will probably be forced to implement it soon for the app I'm doing.
The question says it all. The wxWindows docs describe a class method which isn't implemented in Python, and by snooping around, I haven't found anything yet.
The question says it all. The wxWindows docs describe a class method which isn't implemented in Python, and by snooping around, I haven't found anything yet.
wxToolTip_Enable(false)
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
It would also be nice if it was easy to share the wxColourData across different ColourWells and/or ColourSelects, so the custom colours can be saved and reset when the app is run again.
After thinking about the API a bit, I've just implemented this: