Print Page | Close Window

Toolkit Pro and Suite Pro v20.2 Released!

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
Printed Date: 01 July 2022 at 9:51pm
Software Version: Web Wiz Forums 12.04 -

Topic: Toolkit Pro and Suite Pro v20.2 Released!
Posted By: astoyan
Subject: Toolkit Pro and Suite Pro v20.2 Released!
Date Posted: 14 May 2021 at 4:38pm
Codejock Toolkit Pro and Suite Pro v20.0 (Beta 1) Released!
(beta versions available only for the users with active subscriptions)

The release contains new features and fixes to be included into the final release of version 20.0, those include frequently requested strict C++ standard code compliance fixes, Windows 10 theme for various controls, MDI tear-off windows, the new Preview control, 3D charts additions and a number of highly requested fixes and minor features.

MDI tear-off windows
Improve productivity of the users of your software by allowing them working simultaneously in a number of detached document windows in multi-monitor or wide screen environments:

Windows 10 theme
Make your command bars and other controls look like Windows 10 in a desired accent color:

The Preview control
The new Preview control allows previewing various common file types or whatever file types that have system preview provider installed, those include common image formats like BMP, PNG, JPG, TIFF, WMF, GIF (including animated images), Unicode and ANSI plain text format, XAML, Outlook message (MSG), PDF, XPS, Microsoft Visio, Microsoft Word, Microsoft Excel, Microsoft PowerPoint and many other formats that Windows Explorer can generated previews for.

3D charts additions
Besides the new Funnel 3D chart style added, all existing 3D charts have been updated with the new configurable chart transparency feature that allows to achieve a glassy effect.

C++ standard conformance support
At Codejock we understand the need to follow the most strict C++ coding standards. Once this is fully supported by the underlying dependencies, we enable it in ToolkitPro. Starting with version 20 the user can enjoy enabling C++14 or C++17 coding standards using /std:c++14 or /std:c++17 compiler options respectively, in addition disabling permissive compiler mode, enabled maximum warning level and making any warning to be treat as an error (/permissive-, /Wall, /WX), and all that will result in a clean ToolkitPro compilation.

We'll be happy to hear all feedback from you about this release and we're grateful in advance for sharing your thoughts with us. Please refer to our release notes for this version on our website" rel="nofollow - , and use the following communication means for sharing your feedback with us:
  •" rel="nofollow -
  •" rel="nofollow -
  •" rel="nofollow -
We understand the importance of all feature requests. We are working our best to deliver all promised features as fast as possible. We hope that this release will exceed your expectations. More are in the works for future releases too.

-Codejock Development Team!

Posted By: dbrookes
Date Posted: 24 May 2021 at 2:07am
I was going to send this in a support request but I guess its better to give some feedback on here..." rel="nofollow -

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" rel="nofollow - . See fourth screenshot.

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

Posted By: dbrookes
Date Posted: 24 May 2021 at 2:21am
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).


Posted By: rdhd
Date Posted: 27 May 2021 at 3:59pm
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.

Posted By: markr
Date Posted: 29 June 2021 at 5:57pm
> It looks like something funky is going on with the resources.

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

Even the samples have these issues.

- Mark

Posted By: rdhd
Date Posted: 03 August 2021 at 2:00pm
Hi dbrookes,

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

Posted By: rdhd
Date Posted: 03 August 2021 at 2:52pm
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.

Posted By: rdhd
Date Posted: 03 August 2021 at 4:08pm
So far what I build doesn't matter. The sample's CMainFrame has an embedded CXTPTabClientWnd and it has an m_strIniFileName member. That gets initialized to "" as the app starts up. Then, the memory for the string's m_pszData gets overwritten after stepping out of the tab client constructor and into the CXTPImageManager constructor. That last constructor is calling the CXTPCmdTarget::CXTPCommandTarget constructor and then CCmdTarget::CCmdTarget and then CObject::CObject at which time the debugger immediately detects the memory overwrite.

Posted By: astoyan
Date Posted: 03 August 2021 at 6:08pm
That and a number of other reported issues have been fixed.

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.

An update v20.1 is expected to be released by the next week.

Posted By: rdhd
Date Posted: 03 August 2021 at 8:35pm
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.

Posted By: rdhd
Date Posted: 04 August 2021 at 9:41am
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.

Posted By: MGebler
Date Posted: 10 August 2021 at 10:38am
The CXTPTaskDialog class does not work anymore. 
I've also tried your sample application (VistaTaskDialog) and it seems that something in the CreateFromResource method goes wrong.

Best Regards

Posted By: markr
Date Posted: 13 August 2021 at 5:41pm
@MGebler, are you loading your task dialogs from an XML file? That functionality does indeed appear to have regressed in the v20 release. If I run the "Vista Task Dialog" live sample, none of the xml resource samples on the "Samples" tab are working as expected.

You seeing same?

Posted By: MGebler
Date Posted: 14 August 2021 at 4:48am
Yes, I see the same behaviour.

The call

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

fails in the method

 CXTPDOMNodePtr CXTPPropExchangeXMLNode::GetProfileNode(LPCTSTR strSection)

Posted By: astoyan
Date Posted: 14 August 2021 at 12:48pm
That issue with selecting an XML node in has been fixed in v20.1. Thank you

Posted By: fjosesen
Date Posted: 16 August 2021 at 10:54am

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

Kind regards

Products: Suite Pro (ActiveX) v18.0.1
          Toolkit Pro (MFC) v18.0.1
Platform: Windows 10 (64bit)
Language: VC++ 2013 (MFC)

Posted By: rdhd
Date Posted: 10 September 2021 at 4:08pm
It is available now.

Posted By: Sven
Date Posted: 15 September 2021 at 11:18am
Which sample uses the new MDI tear-offs?

Posted By: Pesci7
Date Posted: 15 September 2021 at 12:24pm

Product: Xtreme ToolkitPro (20.3.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2022 (C++)

Posted By: rdhd
Date Posted: 16 September 2021 at 8:29am
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.

Posted By: Sven
Date Posted: 16 September 2021 at 8:57am
MDITabWindow.exe doesn't have the stickers in the MDI client area.

It looks like GUI_VisualStudio is the right one:

C:\Program Files (x86)\Codejock Software\MFC\Xtreme ToolkitPro v20.1.0\Samples\UserInterface\GUI_VisualStudio

Posted By: rdhd
Date Posted: 16 September 2021 at 9:20am
I'll try that one. The sample I mentioned has tear-offs. Simply open a bouncy window or two, mouse down on the MDI tab and drag it off into space.

Posted By: rdhd
Date Posted: 17 September 2021 at 2:05pm
Utils\Translations\ToolkitPro.ResourceFr.xml still has an untranslated string. Please make this change for ID 9185.

"Active files" to "Fichiers actifs"

Posted By: rdhd
Date Posted: 17 September 2021 at 2:18pm
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)
// 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.

Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 -
Copyright ©2001-2021 Web Wiz Ltd. -