[wxPython] wxGrid click off cell while editor still in process of destruction -> wxAssert

src/generic/grid.cpp line 470

  I'm testing it by starting a wxprop transient-based editor, clicking the "edit" button to shut it down (which closes down the transient frame when the button is destroyed). If I click on another cell while the frame is still visible, but the button has already been hidden/removed, I get the assert.

Not sure how to go about making a small test-case for this, as it's going to require a fairly involved set of code to get a similar delay during destruction/hiding I'm guessing (my code is doing a database commit before completing the process). Should I try (be a few days before I can get to it), or is this something that logically isn't a problem (or has been fixed)?

For now it's the old "so don't do that" fix :slight_smile: ,
Mike

···

_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/

src/generic/grid.cpp line 470

Which version? (So I can ensure line 470 is where I think it is.)

I'm testing it by starting a wxprop transient-based editor, clicking the
"edit" button to shut it down (which closes down the transient frame
when the button is destroyed). If I click on another cell while the
frame is still visible, but the button has already been hidden/removed,
I get the assert.

Not sure how to go about making a small test-case for this, as it's
going to require a fairly involved set of code to get a similar delay
during destruction/hiding I'm guessing (my code is doing a database
commit before completing the process). Should I try (be a few days
before I can get to it), or is this something that logically isn't a
problem (or has been fixed)?

Yes, please. (Since I have almost no idea what you are describing in the
first paragraph above :wink:

···

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

pre4 is the version.

Will try to get a test case, but I'm still stymied on how to do it... will have to try something like counting to a billion a few times to get the delays (just came back from testing on client's (ancient) machine, there the crash occurs all the time). That, however, is for tomorrow. Now I sleep.

Enjoy,
Mike

Robin Dunn wrote:

···

src/generic/grid.cpp line 470

Which version? (So I can ensure line 470 is where I think it is.)

I'm testing it by starting a wxprop transient-based editor, clicking the
"edit" button to shut it down (which closes down the transient frame
when the button is destroyed). If I click on another cell while the
frame is still visible, but the button has already been hidden/removed,
I get the assert.

Not sure how to go about making a small test-case for this, as it's
going to require a fairly involved set of code to get a similar delay
during destruction/hiding I'm guessing (my code is doing a database
commit before completing the process). Should I try (be a few days
before I can get to it), or is this something that logically isn't a
problem (or has been fixed)?

Yes, please. (Since I have almost no idea what you are describing in the
first paragraph above :wink:

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

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

--
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/

I have discovered the source of the problem. The slowdown and the assert message were both caused by the same change, but were unrelated otherwise, finally being able to get at the source this evening (was a CVS misconfiguration on my part) I realised there was no way it could be related to the speed. Explaining is complex, but I figure others might benefit from it...

Summary:
  Calling wxGrid::RegisterDataType twice with the same typeID, but different renderer and editor object instances (same classes) was replacing the original instance of the editor (which had had Create called) with one which hadn't had Create called. The assert noticed that there was no control and was complaining about it.

What does this have to do with the slowdown?:

My system, which had previously only been asking the grid to reset when a local property changed was changed Monday to use automatic updates so that changes in a database would be automatically reflected in the object property editors. In implementing the "general refresh" code, I had done two things:

  I was calling code which re-registered all of the data types to be sure they were up-to-date (causing the assert to be triggered). This code was part of the generic "set the property set for editing" code, and I had re-used it in my refresh code thinking "make sure the property set value is current" (it could change when/if I implement an editing type for changing an object's properties at run time).

  The code wound up doing not 1 refresh, but two (once for the setting of the data types, once for the setting of the objects being edited (both methods originally having been designed for initial setup of the dialog)), with each refresh also doing an auto-resize for both cols and rows. I was getting my 60-100 visible cells (with 1/2 of those using custom Python renderers) rendered 2 times (plus the sizing) for every change to the database (not to mention the overhead of the application itself). End result was that pause on a high-end machine was up to 3 or 4 seconds for every interaction. Pause on client's machine was 6+ seconds in many cases, a complete freeze of the machine in others.

After commenting out the auto-resizing, and eliminating the call that re-registers the data types, response times are back down to sub-1-second on the same high-end machine.

Oh, and sorry for the muddled error report, Robin, been cramming to get this milestone finished for this afternoon, so my brain's been a little fried.

Enjoy yourselves,
Mike

Mike C. Fletcher wrote:
...

src/generic/grid.cpp line 470

...

I'm testing it by starting a wxprop transient-based editor, clicking the
"edit" button to shut it down (which closes down the transient frame
when the button is destroyed). If I click on another cell while the
frame is still visible, but the button has already been hidden/removed,
I get the assert.

...

Yes, please. (Since I have almost no idea what you are describing in the
first paragraph above :wink:

...

···

_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/