wxTabMDIParentFrame::ProcessEvent() Problem

[disasm]

In wxTabMDIParentFrame::ProcessEvent() it has a mechanism to protect against processing the same event repeatedly. IMO, this is a bug. If the events are mouse movement or paint events or something like that, then there is no problem. But consider an application that does video capture and uses events to send the next frame of video data to a wxTabMDIParentFrame window. With this duplicate event blocking code in place, the frames will get dropped if, for any reason, wxTabMDIParentFrame::ProcessEvent() gets called again.

I would like to suggest that the duplicate event blocking code have a conditional if statement that checks to make sure the event is of a certain type before blocking duplicates. What do you think?

P.S. - I would also like to suggest that, instead of making this a static local function variable, the inEvent variable be made a class member variable. This way, multiple wxTabMDIParentFrame window's can co-exists and both process events properly.

[Ben]

Hello,

I totally agree! Sorry that the tab portion is still somewhat unrefined-- we still have a lot of work to do on it. All of the bugs have not been ironed out. Since we need this tab work done for our own software packages, you can be sure to see some movement on it in the coming weeks.

Best,
Ben

[disasm]

Hi Ben, I see that you've made some excellent improvements to wxAUI in the last few days. Thanks!

I was just wondering if you might be able to address this problem while you're at it?

This problem, and being able to catch tab closure so I can hide the tab instead of close it are my only remaining grievances with wxAUI now.

Thanks for an excellent library!

[disasm]

Any word on this?

IMO, this is a serious bug in wxAUI. I continue to run into problems with the code that does not let multiple same events get processed. Most recently, I am seeing a problem where I process a ID_FILE_SAVE command event (wxEventType == 10054). I check the document and determine that it is a new document, so I call ProcessCommand(ID_FILE_SAVE_AS) so that it will pop up a file selection dialog for them. But wxAUI filters this out for me because another command event (wxEventType still == 10054) has been received while we are still processing a previous one.

Hopefully this problem will get fixed before wx 2.8 is out the door.

[Ben]

Hi disasm,

I'll look at it today.

Thanks,
Ben

[Ben]

Hi disasm,

I checked in what is probably the right fix. Could you test it ASAP and let me know if it solved your problem?

Thanks much,
Ben

[disasm]

Sure thing, I'll be able to test this a little later today.

I just took a quick look at the code changes you made, and I have a question about it. Now correct me if I am wrong, but doesn't the wxWidgets event processing system Clone() each event before it is sent? So in that case, since the new code compares event object pointers directly, does it really have any effect?

What was the original purpose for this event filtering code anyways? Perhaps it would be better to just remove it?

[Ben]

Hi disasm,

Yes, it does Clone() it, but this is after the clone takes place, if I am correct. The code definitely has the intended effect, which is to block an infinitely recursive call.

Thanks,
Ben

[disasm]

Ben, in my testing, this solution seems to work great! Thanks!!