wxAui/wxAuiMDI

[SalmonsSteve]

I am currently developing an application using wxAui. The application window is the top level of a suite of programs. wxAUI is working great for a number of the features that I want to implement however, I am having one major problem. The parent window needs to be able to launch the other applications into their own framed windows. I wanted to be able to utilize the ribbon on the parent to control functions in the child window using AUI but I want the look of each application having its own frame since I don't anticipate them being docked entities. I also want the main frame to be able to control destruction of all open frames when it is closed. The aui pane border just doesn't do it for me for two reasons, one is that the programs can be purchased independently so I would like to reuse most if not all of the code I create for those. The other is that it just doesn't provide that more robust UI look that you expect from an application versus the look of a feature in an application (if that makes sense).

I notice that wxAuiMDIChildFrame is actually inherited from a wxPanel instead of from wxMDIChildFrame. Is there a reason that it was done this way? I suspect it was just due to wanting a dock-able solution without a frame that is consistent with the look of other AUI Panes.

At this point I see a couple of options:
1) Inherit a class from wxMDIChildFrame and implement functionality that would make it a wxAuiMDIFramedChild. (I haven't explored this but to the ear it sure sounds like a lot of code to sift through and to write)
2) Write a function that will create a pointer to a wxFrame that can be stored by the parent window and implement functions that would let the parent and child interact in such a way that ribbon events are passed to the last active child in an appropriate manner. (This also sounds relatively substantial as I think about it).
3) Figure out a different way after entertaining the suggestions of others. <-- This is where I am at right now.

Does anybody know of an implementation similar to what I am talking about? Maybe classes written for a framed aui child? Am I wanting too much from AUI? As I understand it, the AUI classes are really just for management of toolbars and such as well as the docking within the managed frame. Maybe curbing my expectations of AUI would lead to a more open mind about how these other applications need to be written and spawned from within this program. Any feedback or suggestions are greatly appreciated, thank you in advance.

[ONEEYEMAN]

Hi,
The inheritance issue had been discussed previously.
It is possible that there is an implementation already - either on the trac.wxwidgets.org or somewhere on the github.
Also, did you check the Git HEAD?

And of course:
1. What version of wx do you use?
2. What platform?
3. What toolkit (if applicable)?

Thank you.

[SalmonsSteve]

Thank you for your response. I am currently using version 3.1.1 on Windows 10 though I plan on this code being written to work on linux or Mac as well. MinGW and Code::Blocks are being utilized. I am not using any toolkits at the moment, I suspect that I probably won't through the course of this development. I will probably end up using a few libraries from wxcode at some point but for the time being I will be concentrating on getting the user interface function with (hopefully) only the libraries included in wxWidgets.
After reading your response I went to trac.wxwidgets.org and I see that it appears wxAuiMDIChildFrame now inherits from wxMDIChildFrame as of 3.1.2. I had avoided that upgrade as I started this code days before the release and wanted to stick with a stable release versus the development release. I hadn't really read the info on 3.1.2 once I saw the word "development". It seems that if I had read literally two more lines on the home page I would have seen that 3.1.2 is being encouraged for use in production code.
In any case, my searches prior to going to trac.wxwidgets.org had really not yielded any decent results and I was not able to find where this inheritance issue had been previously discussed. Maybe too many hours at the PC, who knows. So, armed with this new (to me) information about 3.1.2 I will be compiling new libraries and converting frames over the weekend. Again, thank you for your response.