Yes, that’s what I am doing right now. But I tough there could be a way to cast the MXS rollout to a ICustToolbar or something like that but couldn’t get that to work.
So I am stuck with just parenting the control and using all the methods and properties available in the CUIFrame.
all the same for me… RegisterDialogBar is a black box… They doing something… not wrong … but not smart.
at least it was ‘smart’ enough for that time (ending of 1990th – beginning of 2000th).
i almost solved the problem, but i hooked all CUIFrame messages to get it. This is wrong! It has not to be so complicated!
I too though it was something much simpler than this. Perhaps an additional handler to manage this in the WindowProc.
It would also be good to have the “dock” style along with the other rollout styles, without the need to register and unregister. Or as an additional property.
I don’t know, maybe this would break something in the architecture that I am not seeing right now. But I don’t understand why we need to frame a window with another window.
Yes. You are right. As all about below…
When the system “register” a dialog it hooks it’s original WinProc and replace with a different which doesn’t allow resizing(sizing), just by overriding some window messages. The system allows to do this overriding at the time of LinkToCUIFrame or with frame by using InstallMsgHandler
As I guess the system stores the original WinProc at time of registering and returns it back on unregistering. I do it in several projects myself. So I know how it’s possible.
The problem – I can’t do the same because we don’t have access to current CUIFrameMsgHandler which we need to store and restore. We can only completely override it. And handle all window messages ourselves.
It’s correct again. That’s what I’ve already implemented. I can create a dialog in already dockable state.
We have to frame. It’s how the system works. Frame is a special class which works with max panels. Max panels are not a windows. They are just a ‘signals’ how to draw max view (which includes panels and viewports).
To be able to resize a docked dialog I have to override it’s frame window WinProc. I did it… but it’s very complicated and unsafe solution (IMHO). It needs a lot of testing and debugging (meaning a time, which I don’t have now).
So I’ve decided to make a dialog ‘dockable’ mode, and I can put any dialog in this mode with correct window size (the built-in solution set a dialog in wrong by size frame).
The resizing in ‘docked’ state is a cool feature, but I can live without it now. At least I have mechanism to set a dialog in ‘dockable’ state and return to a ‘dialog’ state without a visible window resizing issue (again… the built-in solution drives me crazy because of that).
And I’m absolutely agree – the ‘dockable’ dialog state must be an option of createDialog method. It’s the real reason why I started this “journey”.
The resize issues you are still having are when the dialog is docked and you want to resize it that it does not redraw the UI correctly?