What is the best place to catch my main frame being destroyed,
so I can write the size and position to a database for recall
next time the app is launched?
I tried __del__, but I think that is too late (the wx object is
already gone, I believe).
--
Paul
Would catching the EVT_CLOSE event work?
On Sun, 14 Dec 2003 20:03:31 -0800 Paul McNett <p@ulmcnett.com> wrote:
What is the best place to catch my main frame being destroyed,
so I can write the size and position to a database for recall
next time the app is launched?I tried __del__, but I think that is too late (the wx object is
already gone, I believe).
Scott writes:
Would catching the EVT_CLOSE event work?
Yes I could catch the event, I guess. Thanks!
--
Paul
You're welcome. It's nice to help someone else for a change. 
On Sun, 14 Dec 2003 20:11:18 -0800 Paul McNett <p@ulmcnett.com> wrote:
Scott writes:
> Would catching the EVT_CLOSE event work?
Yes I could catch the event, I guess. Thanks!--
Paul
What about overloading Destroy() instead of __del__()?
/Jean Brouwers
Paul McNett wrote:
What is the best place to catch my main frame being destroyed, so I can write the size and position to a database for recall next time the app is launched?
I tried __del__, but I think that is too late (the wx object is already gone, I believe).
Jean Brouwers writes:
What about overloading Destroy() instead of __del__()?
That didn't appear to work at all. While I've done this with
other windows, it never got called in my wxMDIParentFrame.
--
Paul
Jean Brouwers wrote:
What about overloading Destroy() instead of __del__()?
That won't work if the Destroy call is initiated from within C++ code. Redirecting virtual method calls from C++ to overloaded Python methods requires extra code, complexity and runtime overhead in the wxPython wrappers, so I currently only allow for it sparingly.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin,
Thank you for responding. It is
good to learn something new, 
/Jean Brouwers
Robin Dunn wrote:
Jean Brouwers wrote:
What about overloading Destroy() instead of __del__()?
That won't work if the Destroy call is initiated from within C++ code. Redirecting virtual method calls from C++ to overloaded Python methods requires extra code, complexity and runtime overhead in the wxPython wrappers, so I currently only allow for it sparingly.
Actually, if Destroy() could be overloaded for *all* wx
objects from Python that might be very helpful.
For example, to avoid deadObject problems. Or in general
the Python level can at least be aware what the C++ layer
is doing or about to do.
Does this make any sense?
/Jean Brouwers
Jean Brouwers wrote:
Robin,
Thank you for responding. It is
good to learn something new,/Jean Brouwers
Robin Dunn wrote:
Jean Brouwers wrote:
What about overloading Destroy() instead of __del__()?
That won't work if the Destroy call is initiated from within C++ code. Redirecting virtual method calls from C++ to overloaded Python methods requires extra code, complexity and runtime overhead in the wxPython wrappers, so I currently only allow for it sparingly.
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Jean Brouwers wrote:
Actually, if Destroy() could be overloaded for *all* wx
objects from Python that might be very helpful.For example, to avoid deadObject problems. Or in general
the Python level can at least be aware what the C++ layer
is doing or about to do.Does this make any sense?
It does, but unfortunatly the way things are currently[1] done it is pretty much impossible. It is not as simple as doing it in the wrapper for wxWindow::Destroy and letting it be inherited. I have to derive a new Python aware class for each class that needs to allow overriding Destroy, and implement in each of those the new method that checks for a Python implementation and calls it if it is present.
[1] I say "currently" because the new version of SWIG I am using for 2.5 and beyond has a new feature that may let me automate this. I have opted to *not* try using it at all yet as sometimes it is better to use the bad thing that you know and understand than the good thing that you don't. After I get the first 2.5 release ready for public consumption then I plan on experimenting with that new feature and see if it will allow me to easily support overridable virtual methods in more (or all!) classes without too much overhead.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
What I am trying to do is make a wxGrid smaller by removing the bottom row.
Anyone know how to do this. I can remove a row, but it just clears out the
cells. The cells are empty, but they still remain.
-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Monday, December 15, 2003 2:32 PM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] Catching a frame being destroyed
Jean Brouwers wrote:
Actually, if Destroy() could be overloaded for *all* wx objects from
Python that might be very helpful.For example, to avoid deadObject problems. Or in general the Python
level can at least be aware what the C++ layer is doing or about to
do.Does this make any sense?
It does, but unfortunatly the way things are currently[1] done it is pretty
much impossible. It is not as simple as doing it in the wrapper for
wxWindow::Destroy and letting it be inherited. I have to derive a new
Python aware class for each class that needs to allow overriding Destroy,
and implement in each of those the new method that checks for a Python
implementation and calls it if it is present.
[1] I say "currently" because the new version of SWIG I am using for 2.5 and
beyond has a new feature that may let me automate this. I have opted to
*not* try using it at all yet as sometimes it is better to use the bad thing
that you know and understand than the good thing that you don't. After I
get the first 2.5 release ready for public consumption then I plan on
experimenting with that new feature and see if it will allow me to easily
support overridable virtual methods in more (or all!) classes without too
much overhead.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
Use this piece in your table *or* grid class, where appropriate:
# update the number of rows
grid.BeginBatch()
m = wxGridTableMessage(table, # the table
wxGRIDTABLE_NOTIFY_ROWS_DELETED, # what
num_rows - 2, # from here
1) # how many
grid.ProcessTableMessage(m)
grid.EndBatch()
/Jean Brouwers
It from an earlier message I sent:
> PS) Here is what the ciritical code for grid update now looks
> like. It can be part of a grid or table method, but make sure
> to use the correct object in various calls.
>
> ....
> # don't call SetTable() more than once;
> # use False to prevent table from being
> # destroyed when the grid is deleted
> grid.SetTable(table, False)
> ....
> # update the number of rows
> grid.BeginBatch()
> if new_num_rows > old_num_rows:
> m = wxGridTableMessage(table, # the table
> wxGRIDTABLE_NOTIFY_ROWS_APPENDED, # what
> new_num_rows - old_num_rows) # how many
> grid.ProcessTableMessage(m)
> elif new_num_rows < old_num_rows:
> m = wxGridTableMessage(table, # the table
> wxGRIDTABLE_NOTIFY_ROWS_DELETED, # what
> new_num_rows, # from here
> old_num_rows - new_num_rows) # how many
> grid.ProcessTableMessage(m)
> # update number of columns (similarly)
> ....
> grid.EndBatch()
> # not sure about this ...
> m = wxGridTableMessage(table, wxGRIDTABLE_REQUEST_VIEW_GET_VALUES)
> grid.ProcessTableMessage(m)
> ....
> # force row heights to default (superfluous?)
> h = grid.GetDefaultRowSize()
> grid.SetDefaultRowSize(h, True)
> ....
> # update the scroll bars
> try: # may be depricated
> grid.AdjustScrollbars()
> except: # jiggle the grid
> w, h = grid.GetSize() #
> grid.SetSize((w+1, h+1))
> grid.SetSize((w, h))
> # finally, update screen
> grid.ForceRefresh()
Henry Grantham wrote:
What I am trying to do is make a wxGrid smaller by removing the bottom row.
Anyone know how to do this. I can remove a row, but it just clears out the
cells. The cells are empty, but they still remain.-----Original Message-----
From: Robin Dunn [mailto:robin@alldunn.com] Sent: Monday, December 15, 2003 2:32 PM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] Catching a frame being destroyedJean Brouwers wrote:
Actually, if Destroy() could be overloaded for *all* wx objects from Python that might be very helpful.
For example, to avoid deadObject problems. Or in general the Python level can at least be aware what the C++ layer is doing or about to do.
Does this make any sense?
It does, but unfortunatly the way things are currently[1] done it is pretty
much impossible. It is not as simple as doing it in the wrapper for
wxWindow::Destroy and letting it be inherited. I have to derive a new
Python aware class for each class that needs to allow overriding Destroy,
and implement in each of those the new method that checks for a Python
implementation and calls it if it is present.[1] I say "currently" because the new version of SWIG I am using for 2.5 and
beyond has a new feature that may let me automate this. I have opted to
*not* try using it at all yet as sometimes it is better to use the bad thing
that you know and understand than the good thing that you don't. After I
get the first 2.5 release ready for public consumption then I plan on
experimenting with that new feature and see if it will allow me to easily
support overridable virtual methods in more (or all!) classes without too
much overhead.--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org