I was going to send this in a support request but I guess its better to give some feedback on here...

https://imgur.com/a/CNuVJje" rel="nofollow - https://imgur.com/a/CNuVJje

It looks like something funky is going on with the resources. A lot of the built-in symbol buttons like menu drop-down icons, docking pane buttons and so on are incorrect. For example drop downs are ellipses, check marks are eject icons. I'm sure someones noticed this by now though. See first screenshot.

The Windows 10 theme is a nice addition, especially being able to set a custom accent colour, but I feel that there are a few parts of it that don't look right.

  - The docking pane title bars have a small font and show the gripper in them. This doesn't really look modern. I feel like larger text and no gripper would look better (like the Office 2016 theme). See first screenshot.

  - The dark colour tooltips have dark text on a dark background. (xtpToolTipResource style). See second screenshot.

  - The glowing window frame shadow doesn't really fit the style. See third screenshot.

  - I feel the dark theme ribbon backstage background is too dark (its completely black). See third screenshot.

  - backstage view menu separators on the light theme are dark (I guess thats dependant on the accent colour though...).

  - the colour window caption shouldn't show when the backstage is visible I think. also should the ribbon caption be centered? See third screenshot.

  - the updated sample theme dialog doesn't seem to initialise/update its colour picker button to the current accent colour properly.

  - not really a complaint but a request, it would be nice to see a box around collapsed groups like Office or Windows Explorer ribbon does. we patch this into the Office 2016 theme ourselves stealing colours from combo boxes https://pastebin.com/KFTmd76U" rel="nofollow - https://pastebin.com/KFTmd76U . See fourth screenshot.

I guess this is work in progress so I shouldn't be too harsh :), these are just my opinions as well...

I also wanted to post something about the new MDI tear-off stuff. This is pretty cool.

We've actually been using the method that the MDITabWindow sample provides where the MDI frame/view is reparented into a docking pane. The problem with this method is its reliance on focus to determine if that floated view in focus (active) and therefore if we should route mainframe command/notify messages to it. This means if you are doing something in this view and click a command or something on the mainframe ribbon/menus/toolbars/status bar the floated view loses focus to mainframe. Therefore commands/notifies are no longer routed to it even though we didn't actually activate another view. The problem being its not actual part of the mainframe MDI at that point.

We were hoping that this new method would be able to handle this sort of thing properly but at the moment the Visual Studio sample doesn't seem to at all. For example if you float a new untitled view and press save on the main frame toolbar it will save the mainframe view not the floating one that was in focus. Actual Visual Studio handles this sort of thing, will we be able to as well? I understand MFC doesn't exactly make this easy...

p.s. the Visual Studio sample is a bit crashy when tearing off a bunch of panes.

One part of this that worries me is how the tear-off action temporarily changes the CWinThread m_pMainWnd pointer to the new target MDI frame window while tearing-off. I feel like this is going to be a trap for a lot of people that rely on AfxGetMainWnd() blindly to retrieve their mainframe  MDI window. I guess thats kind of an us problem not an XTP problem but I don't think its an uncommon pattern. I'm curious what the reason for doing this is (I'm sure it is justified).

/rant

Any other users besides dbrookes give the tear offs a good test. I have been adding "floating" MDI windows to our app without changing CodeJock. That's about to change because if I have a floating docking pane and it has focus, closing the pane results in the docking pane manager calling GetSite and then setting focus on the site. That causes my floating frame to be deactivated and the main frame to be activated.

We have our own ribbon class and some of my changes involve not letting the WM_MOUSEACTIVATE message activate the window. I did that for the ribbon and toolbars so that when I user clicks the ribbon to run a command, it doesn't activate the main frame.

I have a registered windows message to "get the active frame", which fixes issues like this in the docking pane manager. As it is, it looks like in this case I have to override ClosePane and implement RemovePane so I can bypass this GetSite call in RemovePane. Luckily we subclass from DPM but I'll still have to copy code and then keep it up to date.

Now, one big thing I have not found a work-around to - If a docking pane is attached to the main frame and my floating frame is active, I have not found a way to let the pane client window "function properly" while not activating the main frame. Floating panes are not a problem. I just change owners whenever the user activates a floating frame. For example, any pane client window that has a button the user can click ends up sending my floating frame to the background.

Mostly all my framework is in place. I'm just busy chasing calls to create dialogs and other UI elements that need to be parented to the active frame. I didn't know CJ was in the process of doing floating MDI windows but I suspect there will still be a lot of work to get all the UI elements working together to avoid frame flopping. And, I did not even consider changing that m_pMainWnd pointer. Too chicken to do that. But, I haven't really found the need too.

One other issue I had to address. Once a window is up, such as a dialog that is not modal, as a user changes MDI windows, either by tabbing or mouse activating or creating a new floating window etc., I have to keep track of such windows so I can switch owners or set the parent. That too avoids frame flopping. Its how I make sure a floating docking pane is frames friendly as well as other windows we launch that are persistent.

dbrookes, thanks for the list. When I get time, I'll pull, build and give their tear offs a test in their sample app. But, really, I'm more interested in how well it works in a real app like ours.

Unfortunately, it appears that these problems are still present in the v20.0 official release.

Even the samples have these issues.

- Mark

Hi dbrookes,

What sample did you build? I built the MDTabWindow sample. There isn't much there functionality wise.

So I pulled the Toolkit and built x64/debug. Then I built some samples. When I try to run the RibbonMDISample, it crashes right away in CXTPTabClientWnd::CheckComandBarsTheme on line 953. The XTPResourcesImages()->m_strIniFileName appears to be quite invalid leading to a crash in ATL::CSimpleStringT<char,1>::Reallocate();

Anyone able to build and run this sample in x64\debug.

I'll try building more targets and see if I have any luck. I want to see if this sample has floating MDI ability.

The MDI tear-off feature has also been improved, in particular it won't re-create the views upon detaching a frame from its MDI parent. There are still a number of known issues and limitations, we are aware of those and we appreciate all your feedbacks, more improvements to it will be coming with the subsequent released.

Thanks for the reply Astoyan. Any change I can make to the RibbonMDISample that will get it to work now?

As for tear-offs, we don't use the MFC document/view stuff. I got MDI tabs to work long ago by making a method virtual and return the hWnd of our view. If I recall, CJ called to get the active view and then just used the hWnd after that. I reintegrate my change each time I upgrade to a new CJ.

Currently I have our own floating frames (tear offs) implemented. I do use the same MDI frame window class we use for the main app but I have to handle the float and dock (to the main app frame, not docking pane) commands so I can bring all our window/view and any IPA window/view, to the new frame when floating or app frame when docking.

I did notice the one sample I found that ran and showed tear offs has some issues, especially with the view. It doesn't have a ribbon and anytime I tried to use the menu on the app frame, the frames "flip" - the main app frame pops to the top of the z-order and the floating frame goes behind it. Our app uses a ribbon and I solved that problem and that includes clicking on any toolbar docked to the main app and of course the QAT. We didn't want to add the ribbon to the floating frame so the user has to use the main app to start commands in the floating frame.

Alas, currently I have no solution for frame flipping when working with docking panes in general. Docking panes that are floating I have a solution for. But when docked to the main app, controls that get focus that are in a pane cause the OS to activate the app and I can't refuse that request or the user can't use the controls. I didn't look extensively to see if I could refuse the mouse activate request when selecting a pane from a docked container due to that issue.

I pulled the 20 kit and built one of the apps that has docking panes. I still can't undock a pane and move it across multiple monitors if I have different DPI settings. My main monitor is a 4k set to 200%. Dragging the app frame across the monitors works just fine (always has). But, undock a pane. then try to drag accross monitors and it doesn't work. If you manage to get one on a different monitor, when you mouse down to drag it or size it, the displayed rectangles are off. You need to dump the MFC drag/resize code as it only works if you build an app using per monitor awareness for the DPI setting.

Right now in order to correctly and easily place a floating pane on another monitor, our customers still have to dock the pane, move the app and then undock it on the monitor they want it on. Then, move the app back to the monitor it was on. Once undocked on a monitor, the pane can be moved and sized on that monitor.

I've also tried your sample application (VistaTaskDialog) and it seems that something in the CreateFromResource method goes wrong.

Best Regards

 Marcus

You seeing same?

The call

 HRESULT hr = m_xmlParentNode->raw_selectSingleNode(CT2BSTR(strSection), &xmlNodePtr);

fails in the method

 CXTPDOMNodePtr CXTPPropExchangeXMLNode::GetProfileNode(LPCTSTR strSection)

When do you plan to release that v20.1? You mentioned it was planned to be released past week.

Kind regards

MDITabWindow.exe - C:\Program Files (x86)\Codejock Software\MFC\Xtreme ToolkitPro v20.0.0\Samples\ToolkitPro\MDITabWindow

Assuming you installed in that location, that's my full path to the project.

Utils\Translations\ToolkitPro.ResourceFr.xml still has an untranslated string. Please make this change for ID 9185.

"Active files" to "Fichiers actifs"

20.1 still contains a bug that crashed us. It is such an easy fix. In CXTPribbonControlTab::OnSetPopup - after calling m_pCommandBar->InternalRelease, please set this stored pointer to null:

Your code:

         if (m_pCommandBar)
            m_pCommandBar->InternalRelease();
 

// The fix is so simple. One line later:

  

        m_pCommandBar = nullptr;

Whether you can duplicate this crash or not, you test the pointer consistently for nullptr in the source and you have deleted the memory for the object and it cannot hurt to null out the pointer. Otherwise, you risk using this pointer that remains set and pointing to deleted memory if any "unexpected" calls are made when you call CreateTabPopupToolBar a few lines later which is where you assign m_pCommandBar to newly allocated memory.