Hello,
I've been doing some hacking on the MPT sources, but I've run into something that has me stumped.
in a regular MFC application, it is impossible [or at least i haven't figured out how yet] to get a CDialog to work as one of the panes of a CSplitterWnd.
I've provided an example visual studio 2008 project to demonstrate the problem. http://www.mediafire.com/?zwrjmnbxujn
HOWEVER! somehow, modplug manages to make the CModCtrlDlg's inherit literally from CDialog and yet still get drawn onscreen...
now, I don't mean regular updates.. like the OnUpdate and UpdateView.
but *only* the fact that it gets any WM_PAINT events at all.
in MFC, a CDialog inside a CSplitter simply doesn't get paint events whatsoever. You are supposed to use CFormView, which MPT does not.
If you look at the classes CModControlDlg, there is nothing there causing it to get painted.. if you comment out stuff like OnSize, you will see that's not causing it to get painted.
If you look at a class like CCtrlComments, you can see that stuff like RecalcLayout does not do any drawing, UpdateView does not do any drawing. Yes it still draws even if I comment out all the code in UpdateView.
I have tried commenting out tons of stuff like CModControlView::UpdateView which does //if ((pDlg) && (pObject != pDlg)) pDlg->UpdateView(lHint, pObject);
and STILL the dialog gets drawn... it just makes no sense how it's working
To make it short, please just check my solution and then you will wonder. How did MPT avoid that problem?
I don't have much to say about this, but this sounds like something that could explain why some controls in the upper panes are not drawn properly every now and then.
I can verify after looking into the problem a bit more, that the current implementation is wrong. It causes all kinds of problems with updates, graphic updates, command routing, etc. I don't know how Olivier managed to force it to work. They should be CFormViews.
Another Reason to switch to something different? :D
Quote from: "Nola"I can verify after looking into the problem a bit more, that the current implementation is wrong. It causes all kinds of problems with updates, graphic updates, command routing, etc.
This is good to know; thanks for the information.
Quote from: "Nola"I can verify after looking into the problem a bit more, that the current implementation is wrong. It causes all kinds of problems with updates, graphic updates, command routing, etc. I don't know how Olivier managed to force it to work. They should be CFormViews.
I noticed that the CSplitterWnd documentations says that a pane "can be any CWnd object that has the appropriate child window ID". To be more specific, is the problem in OpenMPT that the CDialogs that are used do not have the appropriate child window ID (and what is it in the first place)?
i've had fantasies of modplug with a gtk based interface...
(if it was skinnable... modplug would be the most gorgeous host out there... i'm not kidding)