[wxPython] a simple wxPython example and a few questions about wxPython objects

wxPython Users
1

Here's a simple wxPython example and a few questions about wxPython objects.

I chose a simple example, so the questions are about a wxFrame object,
although the kind of answers I'm seeking would apply to any UI object.

#The following bit of code from the wxPython tutorial creates a simple empty
#window with a title.

from wxPython.wx import wxPySimpleApp, wxFrame
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Hello World")
frame.Show(1)
app.MainLoop()

The questions:

In the example above, what do we call the following items?

  o frame
  o frame.this
  o frame.thisown
  o '_1017b700_wxFrame_p'
  o <C wxFrame instance at _1017b700_wxFrame_p>
              o C wxFrame instance

What are the relationships between these things and the gui elements we see
on the display? What's in the chain of data objects between say "frame" and
what we see on the display? Is there a way to get at the contents of these
data objects from python?

Do all wxPython objects have a this and a thisown? What are they for?

Which of these things must continue to exist so the gui elements to continue
to operate?

These items were found by looking at the gui element object from python. Is
there a way to see more? Is there another way to look at it?

-Pat Callahan
  Acton Ma

P.S. The list of things to question was found in the following interactive
python session:

  When I use dir() on the two python objects created above, I see a few things
  that themselves have empty dictionaries.

    >>> app = wxPySimpleApp()
    >>> dir (app)
    ['saveStdio', 'stdioWin', 'this', 'thisown']

    >>> dir (frame)
    ['this', 'thisown']

    >>> dir (frame.this)
    []
    >>> dir (frame.thisown)
    []

  The actual values of the items in frame:

    >>> frame
    <C wxFrame instance at _1017b700_wxFrame_p>
    >>> frame.this
    '_1017b700_wxFrame_p'
    >>> frame.thisown
    1

2

If you do the same thing in the PyCrust python shell
(PyCrust download | SourceForge.net) you get command auto-completion
whenever you type a dot (such as "app.") that pops up a list of all the
attributes for that object. PyCrust also has a namespace tree view that lets
you drill down through all objects in the local namespace. And you can do
all this while your app is running. Here is a sample session showing some of
the things you can do, including calling the getAutoCompleteList() function
directly to answer your question about what other attributes app and frame
have:

Welcome To PyCrust 0.6.1 - The Flakiest Python Shell
Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
Startup script executed: C:\Code\.pythonrc.py

from wxPython.wx import wxPySimpleApp, wxFrame
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Hello World")
frame.Show(1)

1

dir(app)

['saveStdio', 'stdioWin', 'this', 'thisown']

app.MainLoop()

app.GetAppName()

''

app.SetAppName('My App')
app.GetAppName()

'My App'

frame.GetTitle()

'Hello World'

frame.SetTitle('Goodbye World')
frame.GetTitle()

'Goodbye World'

pprint(shell.interp.getAutoCompleteList('app'))

['AddPendingEvent',
'Connect',
'Destroy',
'Disconnect',
'Dispatch',
'ExitMainLoop',
'GetAppName',
'GetAuto3D',
'GetClassName',
'GetEvtHandlerEnabled',
'GetExitOnFrameDelete',
'GetNextHandler',
'GetPreviousHandler',
'GetPrintMode',
'GetStdIcon',
'GetTopWindow',
'GetUseBestVisual',
'GetVendorName',
'Initialized',
'MainLoop',
'OnInit',
'Pending',
'ProcessEvent',
'ProcessIdle',
'RedirectStdio',
'RestoreStdio',
'SetAppName',
'SetAuto3D',
'SetClassName',
'SetEvtHandlerEnabled',
'SetExitOnFrameDelete',
'SetNextHandler',
'SetPreviousHandler',
'SetPrintMode',
'SetTopWindow',
'SetUseBestVisual',
'SetVendorName',
'__del__',
'__doc__',
'__init__',
'__module__',
'__repr__',
'error',
'outputWindowClass',
'saveStdio',
'stdioWin',
'this',
'thisown']

pprint(shell.interp.getAutoCompleteList('frame'))

['AcceptsFocus',
'AddPendingEvent',
'CaptureMouse',
'Center',
'CenterOnParent',
'CenterOnScreen',
'Centre',
'CentreOnParent',
'CentreOnScreen',
'Clear',
'ClientToScreen',
'ClientToScreenXY',
'Close',
'Command',
'Connect',
'ConvertDialogPointToPixels',
'ConvertDialogSizeToPixels',
'ConvertPixelPointToDialog',
'ConvertPixelSizeToDialog',
'Create',
'CreateStatusBar',
'CreateToolBar',
'DLG_PNT',
'DLG_SZE',
'Destroy',
'DestroyChildren',
'Disconnect',
'DragAcceptFiles',
'Enable',
'FindWindowById',
'FindWindowByName',
'Fit',
'Freeze',
'GetAutoLayout',
'GetBackgroundColour',
'GetBestSize',
'GetCaret',
'GetCharHeight',
'GetCharWidth',
'GetChildren',
'GetClassName',
'GetClientAreaOrigin',
'GetClientSize',
'GetClientSizeTuple',
'GetConstraints',
'GetDropTarget',
'GetEventHandler',
'GetEvtHandlerEnabled',
'GetFont',
'GetForegroundColour',
'GetFullTextExtent',
'GetGrandParent',
'GetHandle',
'GetHelpText',
'GetIcon',
'GetId',
'GetLabel',
'GetMenuBar',
'GetName',
'GetNextHandler',
'GetParent',
'GetPosition',
'GetPositionTuple',
'GetPreviousHandler',
'GetRect',
'GetScrollPos',
'GetScrollRange',
'GetScrollThumb',
'GetSize',
'GetSizeTuple',
'GetSizer',
'GetStatusBar',
'GetTextExtent',
'GetTitle',
'GetToolBar',
'GetToolTip',
'GetUpdateRegion',
'GetValidator',
'GetWindowStyleFlag',
'Hide',
'Iconize',
'InitDialog',
'IsBeingDeleted',
'IsEnabled',
'IsExposed',
'IsExposedPoint',
'IsExposedRect',
'IsFullScreen',
'IsIconized',
'IsMaximized',
'IsRetained',
'IsShown',
'IsTopLevel',
'Layout',
'LineDown',
'LineUp',
'LoadFromResource',
'Lower',
'MakeModal',
'Maximize',
'Move',
'MoveXY',
'PageDown',
'PageUp',
'PopEventHandler',
'PopupMenu',
'PopupMenuXY',
'ProcessCommand',
'ProcessEvent',
'PushEventHandler',
'Raise',
'Refresh',
'RefreshRect',
'ReleaseMouse',
'RemoveChild',
'Reparent',
'Restore',
'ScreenToClient',
'ScreenToClientXY',
'ScrollLines',
'ScrollPages',
'ScrollWindow',
'SetAcceleratorTable',
'SetAutoLayout',
'SetBackgroundColour',
'SetCaret',
'SetClientSize',
'SetClientSizeWH',
'SetConstraints',
'SetCursor',
'SetDimensions',
'SetDropTarget',
'SetEventHandler',
'SetEvtHandlerEnabled',
'SetExtraStyle',
'SetFocus',
'SetFont',
'SetForegroundColour',
'SetHelpText',
'SetIcon',
'SetId',
'SetLabel',
'SetMenuBar',
'SetName',
'SetNextHandler',
'SetPosition',
'SetPreviousHandler',
'SetRect',
'SetScrollPos',
'SetScrollbar',
'SetSize',
'SetSizeHints',
'SetSizer',
'SetStatusBar',
'SetStatusText',
'SetStatusWidths',
'SetTitle',
'SetToolBar',
'SetToolTip',
'SetToolTipString',
'SetValidator',
'SetWindowStyle',
'SetWindowStyleFlag',
'Show',
'ShowFullScreen',
'Thaw',
'TransferDataFromWindow',
'TransferDataToWindow',
'UnsetConstraints',
'Update',
'Validate',
'WarpPointer',
'__doc__',
'__init__',
'__module__',
'__repr__',
'this',
'thisown']

···

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Patrick
Callahan
Sent: Friday, September 28, 2001 8:12 AM
To: wxpython-users@lists.wxwindows.org
Subject: [wxPython] a simple wxPython example and a few questions about
wxPython objects

Here's a simple wxPython example and a few questions about wxPython objects.

I chose a simple example, so the questions are about a wxFrame object,
although the kind of answers I'm seeking would apply to any UI object.

#The following bit of code from the wxPython tutorial creates a simple empty
#window with a title.

from wxPython.wx import wxPySimpleApp, wxFrame
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Hello World")
frame.Show(1)
app.MainLoop()

The questions:

In the example above, what do we call the following items?

        o frame
        o frame.this
        o frame.thisown
        o '_1017b700_wxFrame_p'
        o <C wxFrame instance at _1017b700_wxFrame_p>
              o C wxFrame instance

What are the relationships between these things and the gui elements we see
on the display? What's in the chain of data objects between say "frame" and
what we see on the display? Is there a way to get at the contents of these
data objects from python?

Do all wxPython objects have a this and a thisown? What are they for?

Which of these things must continue to exist so the gui elements to continue
to operate?

These items were found by looking at the gui element object from python. Is
there a way to see more? Is there another way to look at it?

-Pat Callahan
  Acton Ma

P.S. The list of things to question was found in the following interactive
python session:

        When I use dir() on the two python objects created above, I see a
few things
        that themselves have empty dictionaries.

                >>> app = wxPySimpleApp()
                >>> dir (app)
                ['saveStdio', 'stdioWin', 'this', 'thisown']

                >>> dir (frame)
                ['this', 'thisown']

                >>> dir (frame.this)
                
                >>> dir (frame.thisown)
                

        The actual values of the items in frame:

                >>> frame
                <C wxFrame instance at _1017b700_wxFrame_p>
                >>> frame.this
                '_1017b700_wxFrame_p'
                >>> frame.thisown
                1

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwindows.org
http://lists.wxwindows.org/mailman/listinfo/wxpython-users

3

This is rather nice. I'll take a look at the code to see how this is done.

By the way, I had a bit of trouble using the PyCrustAlaCarte.py and
PyCrustMinimus.py demos:

1 Cut and paste does not seem to work in the demo either within it or from
other windows.

2 Exiting the shell by cliking the close box leaves a process running but no
open window. the process did not respond to ctrl/c in the window that
created it. Had to kill the task.

but nice... very nice...

- Pat Callahan
   Acton Ma

···

On Friday 28 September 2001 09:43, you wrote:

If you do the same thing in the PyCrust python shell
(PyCrust download | SourceForge.net) you get command auto-completion
whenever you type a dot (such as "app.") that pops up a list of all the
attributes for that object. PyCrust also has a namespace tree view that
lets you drill down through all objects in the local namespace. And you can
do all this while your app is running. Here is a sample session showing
some of the things you can do, including calling the getAutoCompleteList()
function directly to answer your question about what other attributes app
and frame have:

4

I said earlier that cut and paste did not seem to work in the pyCrust demos.
That is NOT true. Cut and Paste do work.

I'm using PyCrust in Linux, and the usual middle button paste method does not
appear to work. However, Cut and paste within the pyCrust session itself
work just fine by using the right mouse button.

I've had similar problems with other linux applications and wonder what the
problem might be. Is it something missing in the applications or is there
some configuration item for the middle mouse button I'm not aware of yet.

- Pat Callahan
   Acton Ma

5

I can't recreate any of those problems here. If you could provide more
details I'll investigate it further. Please note that pasting is only
allowed when the cursor is at the bottom of the shell editor.

···

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Patrick
Callahan
Sent: Friday, September 28, 2001 9:12 AM
To: wxpython-users@lists.wxwindows.org
Cc: pobrien@sourceforge.net
Subject: Re: [wxPython] a simple wxPython example and a few questions about
wxPython objects

<snip>

By the way, I had a bit of trouble using the PyCrustAlaCarte.py and
PyCrustMinimus.py demos:

1 Cut and paste does not seem to work in the demo either within it or from
other windows.

2 Exiting the shell by cliking the close box leaves a process running but no
open window. the process did not respond to ctrl/c in the window that
created it. Had to kill the task.

but nice... very nice...

- Pat Callahan
   Acton Ma

6

I don't override any of the default cut and paste behavior, other than
disallowing it in certain contexts, so the issue would appear to be one with
wxPython or Scintilla. Unfortunately, I do not have a Linux machine at the
moment, so I have not done any testing under Linux. I do know there are
other Linux users running PyCrust, but I haven't heard any complaints from
them about these items. Sorry I can't give a better answer than that.

···

---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

-----Original Message-----
From: wxpython-users-admin@lists.wxwindows.org
[mailto:wxpython-users-admin@lists.wxwindows.org]On Behalf Of Patrick
Callahan
Sent: Friday, September 28, 2001 9:23 AM
To: wxpython-users@lists.wxwindows.org
Subject: Re: [wxPython] a simple wxPython example and a few questions about
wxPython objects

I said earlier that cut and paste did not seem to work in the pyCrust demos.
That is NOT true. Cut and Paste do work.

I'm using PyCrust in Linux, and the usual middle button paste method does
not
appear to work. However, Cut and paste within the pyCrust session itself
work just fine by using the right mouse button.

I've had similar problems with other linux applications and wonder what the
problem might be. Is it something missing in the applications or is there
some configuration item for the middle mouse button I'm not aware of yet.

- Pat Callahan
   Acton Ma

7

from wxPython.wx import wxPySimpleApp, wxFrame
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Hello World")
frame.Show(1)
app.MainLoop()

The questions:

In the example above, what do we call the following items?

o frame

An instance of the wxFrame Python class.

o frame.this

A "SWIGified pointer" to the instance of the wxFrame C++ class.

o frame.thisown

A boolean value that lets us know if the C++ object should be destroyed when
the Python object is. (In wxPython most of the window objects are destroyed
automatically when their parent is, or when the window is closed, so we
don't need this value at all. But it is auto-generated so no need to worry
about it.)

o '_1017b700_wxFrame_p'

The "SIGified pointer." The hex number is that address of the C++ object,
and it also has the type embedded in it so we can do limited type checking
in the wrapper code. If you look at the Python code for wxFrame you'll see
that self.this is passed to each of the extension module functions that deal
with wxFrame.

o <C wxFrame instance at _1017b700_wxFrame_p>
              o C wxFrame instance

This is just what the wxFrame.__repr__ method returns.

What are the relationships between these things and the gui elements we

see

on the display? What's in the chain of data objects between say "frame"

and

what we see on the display?

wxFrame Python object --> wxFrame C++ object --> platform specific stuff.

Is there a way to get at the contents of these
data objects from python?

Whatever methods (and sometimes attributes) of the C++ objects that are
exposed you can get to in Python. There is almost never any access to the
platform specific bits.

Do all wxPython objects have a this and a thisown? What are they for?

Yes, see above.

Which of these things must continue to exist so the gui elements to

continue

to operate?

The C++ objects. The Python objects will come and go as needed.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

8

I said earlier that cut and paste did not seem to work in the pyCrust

demos.

That is NOT true. Cut and Paste do work.

I'm using PyCrust in Linux, and the usual middle button paste method does

not

appear to work. However, Cut and paste within the pyCrust session itself
work just fine by using the right mouse button.

Yep, we need to add a default event handler to wxSTC for the middle button
to position the caret and then Paste...

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

9

Robin Dunn:

Yep, we need to add a default event handler to wxSTC for the middle button
to position the caret and then Paste...

   IMO this isn't right as the middle button is an X-specific convention and
applies to the primary selection, not the clipboard. Performing a normal
paste would just lead to a confusing and inconsistent UI. As Windows doesn't
have a primary selection or a default meaning for the middle button then it
could be implemented there as a normal paste but that could also be seen as
inconsistent.

   Neil

10

When in Rome, do as the Roman's do.

Implementing the middle button for Linux is consistent with not implementing
it on Windows. I'm not recommending that this behavior be extended to
windows. It shouldn't be. A wx windows Win app should behave like any other
win app. A wx linux app running under X should behave similarly to other
linux apps running under X.

Consistency must be maintained with the wx implementation's platform. As
things stand, the application is absolutely inconsistent with most of the
other applications on my platform and presents an unexpected and unwelcome
departure from the norm. We don't want to do that to any user regardless of
what platform we're targeting.

- Pat Callahan
   Acton Ma

···

On Friday 28 September 2001 07:13, you wrote:

Robin Dunn:
> Yep, we need to add a default event handler to wxSTC for the middle
> button to position the caret and then Paste...

   IMO this isn't right as the middle button is an X-specific convention
and applies to the primary selection, not the clipboard. Performing a
normal paste would just lead to a confusing and inconsistent UI. As Windows
doesn't have a primary selection or a default meaning for the middle button
then it could be implemented there as a normal paste but that could also be
seen as inconsistent.

11

I agree, since wxWindows seems to take this approach anyway (platform
consistency vs toolkit consistency). Tk seems to take the opposite approach
which is probably why Tk-based applications always seem like misfits no
matter where they run.

···

On Friday 28 September 2001 16:36, Patrick Callahan wrote:

Implementing the middle button for Linux is consistent with not
implementing it on Windows. I'm not recommending that this behavior be
extended to windows. It shouldn't be. A wx windows Win app should behave
like any other win app. A wx linux app running under X should behave
similarly to other linux apps running under X.

--
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308