wxAuiMultiNotebook question

[djetter]

I am currently making an IDE-like interface, where you have a pane on the left with a tree, and double-clicking a tree item causes an associated tab in the wxAuiMultiNotebook to appear. Each tab has a single wxTextCtrl.

The problem is, when the user presses the close button, the wxTextCtrl is automatically deleted. Since I can't seem to use the event table to catch the close button event, I won't be able to stop or even know the delete happened. So, if another part of my code keeps a pointer to the wxTextCtrl, that pointer could become invalid at any time.

The best solution I could come up with was to derive a class from wxAuiMultiNotebook, copy the OnTabButton and DeletePage functions from the wxAuiMultiNotebook source code, and copy the EVT_COMMAND_RANGE for the wxEVT_COMMAND_AUINOTEBOOK_BUTTON (so that my derived class's OnTabButton would be called, rather than wxAuiMultiNotebook's). Next, I changed the "wnd->Destroy();" to "wnd->Hide();" in the DeletePage function. This change gave me the desired behavior, but it seems like there should be an easier way to do this.

So, my question is, will there be any fixes in the future that will address this problem? Or am I trying to do something that is sort of seen as outside the scope of wxAuiMultiNotebook? I'm using version 2.7.1, by the way.

[Ben]

Hi,

I definitely see your point. You are right, the way you did this is the only way right now. I'll see what I can do in the next day or so.

Thanks,
Ben

[Ben]

Hi djetter,

I've implemented the event you wanted. Get the latest wxWidgets cvs and let me know if this works for you. I've updated the sample, too, if you need an example.

All the best,
Ben

[disasm]

This new event that you have added is much better. However, I was thinking - currently there are two options when using this event, and they are to veto the event, or allow the event and destroy the tab. Would it be possible to communicate back through this new event whether the tab should be destroyed, just hidden, or if the event should be vetoed?

[Ben]

Hi disasm,

In my thinking, with the new event should not have backflow information, for simplicity's sake. Currently, if I am correct, hiding can be achieved by Vetoing a close event, and then proceeding to remove the page (without destroying the window of course).

Is this correct?

Best,
Ben

[disasm]

In my thinking, with the new event should not have backflow information, for simplicity's sake. Currently, if I am correct, hiding can be achieved by Vetoing a close event, and then proceeding to remove the page (without destroying the window of course).

Is this correct?

Yes, this method works perfectly. It is how I am currently hiding the pages instead of closing them.

I don't have any problems with the current implementation. I just want to make sure I'm doing things in the proper way.

[disasm]

This new event functionality is broken in the latest code. It now always destroys the tabs (and their windows) without ever giving me a chance to process the event and veto it.

I see that you have added an EVT_AUINOTEBOOK_PAGE_CLOSE() handler to wxAuiMDIClientWindow. I believe this is the cause of the breakage. BTW - I have the flags set so that I don't have a close button per tab, but rather one close button at the right of all the tabs.

Ben, can you take a look?

[Ben]

Hi,

If you are using wxAuiMDIClientWindow, you shouldn't try to capture the EVT_AUINOTEBOOK_PAGE_CLOSE() event, which is only meant for code using wxAuiNotebook directly.

wxAuiMDIClientWindow fires (or at least it does for me) EVT_CLOSE, and then I have the ability to veto that event or now.

Let me know if this is the source of your problem. I'm quite keen to make sure this works before the next release.

Thanks,
Ben

[disasm]

I have verified that this is indeed the source of the problem. wxAuiMDIClientWindow is now catching the event, and I don't get a chance to process it.

I don't understand why wxAuiMDIClientWindow is processing this event. Can you explain the reasons for it? You see, the event handler code in wxAuiMDIClientWindow just closes the window and vetoes the event. But that is duplicated code, since the code that sends the event will close the window for you as long as nobody has vetoed it. So it seems like a waste to create an event handler that will do the same thing that would happen anyways without the event handler.

[Ben]

Hi disasm,

I put it in there because it's proper. When a close button is pressed in wxAuiNotebook, it fires the EVT_AUINOTEBOOK_PAGE_CLOSE event. So far, so good.

Next, wxAuiMDIChildFrame calls Close(). Close() is not the end of the story. wxWindow::Close() fires a wxEVT_CLOSE to its parent. The parent has the choice of vetoing this event or not. If the close event is vetoed, nothing happens (which is the intended effect-- no window is closed).

If, however, the close event was not vetoed, wxWindow::Close() calls wxWindow::Destroy(), which is overridden in wxAuiMDIChildFrame to remove the tab from the notebook.

So, it almost boils down to semantics, with one exception: some people like to override Close(), and it was necessary to accommodate this. But I want the event flow to be proper and predictable. That is why this happened.

If you are using the wxAuiMDI* and trying to capture EVT_AUINOTEBOOK_PAGE_CLOSE, then this is the problem. You should be trying to capture EVT_CLOSE instead. If this is not the case, then perhaps this is an issue.

Let me know. If you feel this is still a problem, can you post a little code excerpt for me?

Thanks,
Ben