wxGridCellBoolEditor asserting

[Carl Godkin]

Hi,

After upgrading some code that uses wxGrid to wx 3.0, I've started to see
asserts that say, "any pushed event handlers must have been removed"
when the application exits.

I've read some other messages to this list and understand that (as of wx 3)
there's now
an assert if PushEventHandler() calls are not matched by PopEventHandler()
calls.

However, our code is not calling PushEventHandler(). The only such call is
from wxScrollHelperBase::DoSetTargetWindow().

The assert is coming from a wxCheckBox that is apparently connected with a
wxGridCellBoolEditor
that I am using.

I'm setting it up like this:

m_attr = new wxGridCellAttr;
m_attr->SetEditor (new wxGridCellBoolEditor);

If I use this "bool editor," then I see an assert on exit from a wxCheckBox
destructor.

I have been able to prevent this by adding calls to PopEventHandler() for
the control associated
with the wxGridCellBoolEditor like this:

wxGridCellEditor *gcbe = m_attr->GetEditor(0, 0, 0);
if (gcbe && gcbe->GetControl())
gcbe->GetControl()->PopEventHandler ();

I'm not sure why my workaround is required. Do you have any suggestions as
to what
I should do differently to avoid this?

Thanks very much,

carl

[Vadim Zeitlin]

On Mon, 3 Mar 2014 15:08:45 -0800 Carl Godkin wrote:

CG> If I use this "bool editor," then I see an assert on exit from a wxCheckBox
CG> destructor.

This is not expected to happen, of course, so, as usual, the first thing
to do would be to try to reproduce it in the sample. My suspicion is that
you'll find that you leak the editor in the process of doing it.

CG> I have been able to prevent this by adding calls to PopEventHandler() for
CG> the control associated
CG> with the wxGridCellBoolEditor like this:
CG>
CG> wxGridCellEditor *gcbe = m_attr->GetEditor(0, 0, 0);
CG> if (gcbe && gcbe->GetControl())
CG> gcbe->GetControl()->PopEventHandler ();
CG>
CG> I'm not sure why my workaround is required.

Of course it shouldn't be required, we can write buggy code but we're not
sadists to intentionally force people into doing stuff like that. There is
a bug somewhere...

Regards,
VZ

[Carl Godkin]

Post by Vadim Zeitlin
CG> If I use this "bool editor," then I see an assert on exit from a wxCheckBox
CG> destructor.
This is not expected to happen, of course, so, as usual, the first thing
to do would be to try to reproduce it in the sample. My suspicion is that
you'll find that you leak the editor in the process of doing it.
<http://www.tt-solutions.com/>

Thanks for the reply. I'm sure there's a bug in my code somewhere as you
suggestion
but I'm unclear on something you said. Can you tell me what you mean by
"leak the editor?"

Usually, the wx toolkit is responsible for the memory of its components and
I
currently never delete any wxWindows, etc.

Sounds like there is some cleanup that I should be doing. (Feel
free to point me at the appropriate section in the docs if I'm overlooking
a big
topic.)

Thanks,

carl

[Vadim Zeitlin]

On Tue, 4 Mar 2014 19:01:51 -0800 Carl Godkin wrote:

CG> Can you tell me what you mean by "leak the editor?"

Grid editors (and renderers, and attributes) are ref counted, so it's
relatively easy to leak them (unfortunately).

CG> Usually, the wx toolkit is responsible for the memory of its components
CG> and I currently never delete any wxWindows, etc.

Ownership rules are indeed very simple for windows and most other objects
in wx, as they are simply owned by the library. With grid editors (&c),
it's more complicated because you need to be able to share them between
cells. Hence ref counting. When you create the editor, it has ref count of
1. When you give it to the grid (via SetCellEditor()), it still takes
ownership of it in the sense that it will decrement the ref count, so
something like

grid->SetCellEditor(x, y, new wxGridCellEditor(...));

works as expected. But if you call IncRef() on the editor, e.g. to be able
to share it between two cells, then you must either call SetCellEditor()
twice with the same editor or call DecRef() on it too.

CG> Sounds like there is some cleanup that I should be doing.

If you never call IncRef() you don't have anything to do, and from what
you wrote it looks like you don't. So perhaps my hunch about the editor
being leaked was simply wrong. All I can say is that I don't see such
problem in the grid sample, in spite of the fact that it does use
wxGridCellBoolEditor, so we still need a test case.

Regards,
VZ

[Eric Jensen]

Hello Vadim,

Wednesday, March 5, 2014, 2:53:54 PM, you wrote:

VZ> On Tue, 4 Mar 2014 19:01:51 -0800 Carl Godkin wrote:


VZ> works as expected. But if you call IncRef() on the editor, e.g. to be able
VZ> to share it between two cells, then you must either call SetCellEditor()
VZ> twice with the same editor or call DecRef() on it too.

CG>> Sounds like there is some cleanup that I should be doing.

VZ> If you never call IncRef() you don't have anything to do, and from what
VZ> you wrote it looks like you don't.

A common pitfall (which i fell into myself a little while ago) are
methods like wxGrid::GetCellEditor() where the reference counter for
the editor is implicitly increased. So you have to call DecRef() on
the pointer yourself when you're done with it. It is documented
though.

Eric