|
 
Introduction
Welcome!
We are very happy to announce that we have made the decision to offer our commercial lineup of MFC libraries, including Ultimate Toolbox, Ultimate Grid, and Ultimate TCP/IP to The Code Project community free of charge.
These are the full and complete libraries including source code, documentation, samples and examples.
Ultimate Toolbox, Ultimate Grid and Ultimate TCP/IP come with full source code, and are compatible with Microsoft Visual Studio versions 6.0 through 2005.
The Ultimate Toolbox and line of related MFC libraries products have been powering professional MFC applications for more than 10 years. We realize that there is a very large number of users who are still coding new applications in Visual C++ and MFC and who are looking for effective and proven libraries to enhance their applications, as well as those with legacy code to maintain and update.
By releasing these long standing MFC libraries to The Code Project community we hope that the libraries will continue to grow, evolve and provide a library of useful controls to the development community through the auspices of The Code Project and its members.
Contents
The Ultimate Toolbox forms an extensive collection of classes dealing with many aspects of Windows programming. We have organized the samples and documentation into the following categories - each category page lists the main classes available in that group, and some will contain a link to sample accompanying short article. (Note that most of these are short overviews distilled from the existing documentation - for full class references, refer to the compiled HTML help documentation download.)
Extended MFC UI Controls
Controls that we derived from existing MFC controls and improved upon. These include components such as:
- Office 2003-like and Office XP-like look and feel
- Shortcut bars.
- Extended combo boxes.
- Extended tree controls, including an option tree.
- Masked edit controls - generic and specialized
Classes Extending the MFC UI Framework
These classes expand upon the document-view framework, and provide enhanced functionality such as:
- Customization classes that let your users customize the UI of your application (e.g. the creation/modification of toolbars, menus, etc.).
- Cool tool bar classes, letting you easily add controls to your toolbars (drop lists, check boxes, edit controls, etc.).
- Cool menus, like cool toolbars, allow you to quickly provide advanced functionality to your menus (e.g. display icons/bitmaps).
- Docking windows classes that give your docking windows the functionality and feel of Microsoft applications (e.g. Office 2000).
- Tab view classes that let you display tab views using a wide variety of styles, such as Hot Track, Multi-line and Positioned (left, right, etc.) tabs.
Utility and Shell Extension Classes
These classes can enhance your applications by letting you retrieve system information, implement trace/debugging features, use sound effects, and perform other utility-related operations with ease. Examples of these utility and shell extension classes are:
- A system information class.
- Advanced trace and assert classes.
- Sound effects class.
- XML file parsing class.
- Resource file modification and view classes.
- Data Compression class
- Task bar and Application bar classes.
Graphics Classes

These classes let you display graphics (e.g. BMP, JPEG, etc.) with ease, and the kit also comes with JPEG compression and metafile creation/playback classes. Some examples are:
- JPEG compressor and de-compressor libraries.
- DIB manipulation/conversion classes.
- Metafile classes that come with Ultimate Toolbox provide functionality to load all standard formats of Metafiles (*.wmf, *.emf) from either disk or resource, play back loaded metafiles, and even create new ones.
We've split up the code, samples and documentation of the Ultimate Toolbox into separate ZIP files, to make updates easier.
In general, for a code library such as the Ultimate Toolbox, installation files are a cumbersome nuisance. While they do allow the formality of license agreement acceptance, and are expected of a commercial offering, for our purposes it would be too much trouble to update an entire install in order to accommodate a small update to a core source file or sample - we may in the future provide updates in various formats, from a single class to an entire new distribution as situations warrant. And, of course, the CP community is more than welcome to contribute.
The samples and library projects all reference relative paths with respect to source and include files, and should compile 'out of the box' if the ZIP files are extracted to a common directory - by default, Ultimate Toolbox, which should look more or less like this:
Once the main source and sample distribution is installed, you'll find that most of the samples can be built and run without the need to build any libraries or DLLs. This source code download has been stripped of some of the pre-built libraries that were shipped with previous commercial installations in order to conserve bandwidth - notably the proprietary JPEG libraries, which should be built ( Ultimate Toolbox\lib\JPEG\jpg.dsw ) before building the samples that reference it and the static libraries or DLLs. The jpg VC6 workspace should convert and build without problem with Visual Studio .NET or 2005, and the resulting libraries placed in the Ultimate Toolbox\lib\Libs directory. The static libs and DLL builds in the lib\Build Libs and lib\Build DLLs can then be built.
The static library is handy when using one of the frameworks (docking windows or app customization), but many classes can be easily used directly in your project with the addition of only one or two source and header files - season to taste. For the most part, except for samples that show the use of the DLL or static lib, the samples use the source directly allowing for direct debugging and testing as the need arises.
The CHM DOC file will provide more detailed information on each of the classes and their interfaces, and has an index and full text search - great for 'hmmm... I wonder if there's a class for...' type scientific explorations.
Support for the products will be community based, and will include participation from core developers of the products, long standing and informed users of the products, and other members of the CodeProject.com community.
It is our intention that you be able to use the libraries in any manner you wish, however, specific details of licensing rights, limitation of liability, and other details are included both here, and in a license.txt file included with the downloadable packages
August 2007 - Ultimate Toolbox Version 9.3 forms the initial CodeProject community release.
Version 9.3
New:
- The Hyperbar classes provide an easy way to add some cool UI functionality to any existing or new project that uses a toolbar.
Bug Fixes:
- Missing VS2003 static lib build project files reinstated.
- Vista problems with 'shadow window' rendering addressed.
OXSkins - it's now possible ( and preferred ) to specify the desired skin using an enum
- The
CustomiseManager sample has a minor bug fix, which caused a very rare crash
OutlookStyleDemo : Added ability to change skin type at runtime, and improved overall skin support.
COXBItmapMenu : Fixed bug which caused documents to close when dirty without prompting
COXFrameWndDock::MakeItDockable : Can now specify which sides to support and if we should dock immediately
COXFrameWndDock::AttachMDIChild : Allows users to specify the side to dock to, before it would dock to the first one that was available. Also fixed some docking bugs in this class.
COXListEdit : Added code to send a message to indicate editing has ended when the drop button is pressed.
COXPropertyTree : Added code to send a message to indicate editing has ended when focus is lost.
- Moved all the skinning drawing into seperate classes, so they are all handled polymorphically by the toolbox controls.
COXSizeDockBar::TabAllDockedControlBars : Added code so that the visible bar can be selected, via a pointer or by index.
Version 9.2
Major release feature:
- The entire code base is now compatible with VC++ 2005, VC++ 2003, and VC++ 6. You get zero-warning compilation on VC++ 2005.
Bug Fixes:
COXComboPickerCtrl::OnPaint now checks if the OS version is XP or higher, and if so it uses the default OS painting, else it does custom painting for the combo box arrow
COXCalendarPopup::OnPaint : A bug (missing cast) has been fixed which caused an error in VC++ 7.1 or higher
COXDateTimeCtrl::OnDropDown : The return value has been changed from TRUE to FALSE, thus fixing a bad bug where the parent window never gets to handle the notification.
- The bug in MDI child menus (in skinned mode) where the restore, minimize, and close items were shown in an un-skinned condition has been fixed.
COXSysInfo has been updated to correctly identify all OSes up to Windows Vista.
- The Cool Controls demo had a bug where the Listbox tooltips came up as garbage - this has been fixed.
- Minor bugs have been fixed in the Status Bar demo (which caused garbage to show up in it)
- The Screen Grabber demo has been fixed to not crash on a multiple monitor setup.
- A trivial bug in
COXMDIFrameWndSizeDock::OnActivate has been fixed.
- A bug in
COXTreeCtrl that caused random crashes during drag/drop scenarios has been fixed.
Version 9.0
Major Upgrades:
- The Office 2003 Look and Feel was added. The following Ultimate ToolBox UI elements support this new skin:
- Menus
- Toolbars and menubars
- Docking windows
- MDI tabs and Tear-off tabs
- Shortcut bar
- Properties window
- Status bar
- The Properties window was enhanced to look more like the VS.NET properties window.
Minor Changes and Fixes:
- A bug causing the Caption Painter not to work in Windows XP was fixed.
- A problem casing excessive flashing of the toolbar, menu bar and docking windows under the Office XP skin was fixed.
- A problem causing the close, minimize and maximize buttons of the menu bar to appear too large in skinned Windows XP was fixed.
- A bug causing a floating toolbar to stick to the mouse cursor even after the user has released the button was fixed.
- A GDI leak found in the Office XP skin causing problems in Windows ME was removed.
- Several upgrades to the
COXTreeCtrl were implemented:
- Arrow key navigation was added.
- Various drawing problems involving different back colors were fixed.
- An item indentation problem involving adding a child item to a collapsed parent was fixed.
- A problem in
COXPreviewDialog caused by a font that does not exist in all operating systems was fixed.
- The classes
COXTreeCtrl and COXGridCtrl will draw their sort headers correctly now in Windows XP skinned mode.
- Several upgrades to the
COXPropertiesWnd class were implemented:
OnDeleteProperty() notification was added.
- A method for deleting all properties called
DeleteAll() was added.
- A problem causing a crash if a property is deleted while being edited was fixed.
- A problem causing the combo box drop list not to show in its entirety was fixed.
- Added the following functionality: when editing a property the changes will be accepted if Enter is pressed and discarded when Escape is pressed.
- Fixed a problem in
COXMultiComboBox causing uncontrolled scrolling to the bottom of the drop list in Windows XP skinned mode.
Sample Changes:
- The
SkinsDemo sample was enhanced to show the new Office 2003 look and feel.
- The
SkinsDemo sample was upgraded to demonstrate how to show and hide the different docking windows from the View menu.
New Classes:
COXUxTheme – internal class used by various Ultimate Toolbox classes designed to detect the presence of Windows XP skins and retrieve their color schemas.
Version 8.1
Major Upgrades:
- Visual Studio.NET 2003 full compatibility.
- Enhancements to the VS.NET like properties window: the following property types with their appropriate editors are now supported:
- Text
- Numeric (with the ability to specify the number of decimal places)
- List of items (enumeration)
- Date
- IP address
- Currency
- Color
- Filename
- Directory
- Time (from nanoseconds to days)
- Angle (degrees, radians or grades)
- Length (metric or imperial)
- Temperature (Celsius, Fahrenheit, Kelvin)
- Custom field with a custom editor.
Minor Changes and Fixes:
- The
TVOXS_NOFOCUSRECT style was introduced in COXTreeView to provide the ability to turn off the item focus rectangle for selected items.
- A buggy assertion statement was removed from
COXMDIChildWndSizeDock::Create(…)
- An auto-scrolling problem in
COXMultiComboBox was fixed.
- A bug in
COXPhysicalEdit causing a crash was fixed.
- A bug causing all drop edit controls to show garbage characters in the tooltips was fixed.
- A bug preventing
COXTreeCtrl::SelectItem(…) from having any effect in single selection mode was fixed.
- A bug causing a floating menu to jump away from the mouse cursor was fixed.
Sample Changes:
- The
SkinsDemo sample was enhanced to demonstrate the use of COXPropertiesWnd and all the different type of properties that are supported.
- The
CustomizeManager sample was modified to reflect that in CMainFrame::OnCreate() InitializeToolbars() must be called prior to calling InitializeCommands().
New Classes:
COXPropertyTree – internal class used by COXPropertiesWnd.
COXListEdit – A drop edit control with the ability to display a list of items.
COXListPopup – internal class used by COXListEdit.
COXIPEdit – A an IP address edit control.
COXCalendarEdit – A drop edit control for dates.
COXMonthCalPopup – internal class used by COXCalendarEdit.
Version 8.02
Changes and Fixes:
- When the snapping and tear-off behavior is enabled a floating window could not be resized. This was fixed.
- OXShdWnd.cpp was not added to the build library project causing link errors. This was fixed.
- In
COXPropertiesWnd it was possible to edit a category name, which caused a crash. This was fixed.
- When the extended tree control (
COXTreeCtrl) is automatically populated the user could not expand the tree by single clicking on the plus. This was fixed.
- Some painting problems of the edit control of the extended tree were fixed.
- A problem preventing a date item from being edited in the extended tree was fixed.
- The
COXShdWnd class was not declared as exportable, which caused some link errors. This problem was fixed.
- In the Customize Manager it was possible to turn off the "cool look" of the toolbars while in OfficeXP skin mode, which caused a crash. This problem was fixed.
- A paining problem of
COXCustomTBComboBox with the CBS_DROPLIST style under the Office XP skin was fixed.
- A problem causing
COXSkinnedCombo not to send CBN_SELCHANGE message was fixed.
- A problem causing a floating window not to redraw the window behind it fast enough while moving was fixed.
- In
COXDao the FindNext method will work properly with searches on string values.
Sample Changes:
- A new sample called
CustomizeManager was added to the samples/advanced/ directory. This sample demonstrates how to use COXCustomizeManager. The different steps required are written as comments in the source code. Just search for the string "STEP".
- A new sample called
ExtendedTreeControl was added to the samples/gui/ directory. This sample shows how to achieve the functionality of COXTreeCtrl demonstrated in the downloadable Demo Browser.
- The link errors in the TabViews sample were fixed.
Version 8.01
New Functionality:
- Ability to programmatically tab all docked windows on a dock bar. Use
COXSizeDockBar:: TabAllDockedControlBars(…) to accomplish this.
Changes and Fixes:
COXSkinnedComboBox now sends proper notification messages.
- A combo box custom toolbar button is now properly centered in the Windows XP skin.
- A behavior problem was fixed when the user double-clicks the gripper of a tabbed docking window.
- A behavior problem was fixed preventing the user from moving a docked toolbar to the left edge of the windows without the toolbar going into float mode.
- A crash in
COXPreviewDialog which only occurred in Windows 2000 when compiled with VC7 was fixed.
- Missing files causing links errors were added to the SideBySideToolbars sample.
| You must Sign In to use this message board. |
|
| | Msgs 1 to 25 of 283 (Total in Forum: 283) (Refresh) | FirstPrevNext |
|
|
 |
|
|
Hello,
I am trying to build the Ultimate Toolbox in a VS 2008 project. I fixed all the compiler related issues as mentioned in other posts (GetMenu etc.). Now my project compiles fine. But I am getting the following linker errors: ======== 1>CVTRES : fatal error CVT1100: duplicate resource. type:STRING, name:1659, language:0x0409 1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt ======== MSDN says that some string resource must be using a duplicate ID. I have looked at the string tables in all .rc files (there are a total of 39 .rc files in the Ultimate Toolbox package and 1 .rc file of my own) but can't identify any resource with duplicate ID. Has anyone else been able to successfully build it on VS 2008 platform? I believe that you should run into this problem even on VS 2005.
Any help would be greatly appreciated. Thanks in advance.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi
This sounds a lot like the problem discussed here[^], though that seems to be a VS2003 issue.
If the UT samples/library builds are ok, I'd suggest another check of your apps string table, and a look at resource.h to see if there are any odd defines.
Also, are you compiling on a machine with non-western regional settings, and has this project undergone conversion or was it created with VS2008?
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for the response. I was actually able to diagnose the problem. Here it is:
The file OXMain.rc is a dummy resource file in the sense that it doesn't contain resources of its own and instead includes all the other .rc files in the package. I didn't know that and was including all the .rc files in the build. As a result, they were being included twice resulting in a duplicate resource linker error.
In order to fix it, I simply removed all .rc files but OXMain.rc and now it works fine.
Needless to say, it's a great package and thanks a bunch for that.
As an aside, does anyone know if the other Dundas tools from the past like HyperRichText C++ library are also available for newer development platforms?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
riteshjain wrote: As an aside, does anyone know if the other Dundas tools from the past like HyperRichText C++ library are also available for newer development platforms?
Sorry, but all of the "Hyper" technology products were discontinued and have not been released under a shared type license.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Kudos to Code Project and the authors and contributors to Ultimate Toolbox for this great contribution to the community!
Wondering if anyone else has run into this, I searched and browsed the messages for this article and did not find any reference to this.
I have an older Visual C++ 6.0 / MFC application that I "skinned" successfully with the exception of toolbar handling. The application has a call to LoadBarState( _T("ToolBar") )in the CMainFrame OnCreate which is placed after the toolbars are created, and a call to SaveBarState(_T("ToolBar")) in the OnClose. I discovered that the first time the app runs, it is OK, but when it saves the toolbar state it adds another toolbar for a total of 11 instead of 10 (in the pre-skinning INI file), with an ID of 59408. When restarting the application, this newly added toolbar value causes LoadBarState to assert and then crash in CFrameWnd::SetDockState, ASSERT(pInfo->m_pBar != NULL) on this toolbar id.
After much fruitless debugging of my application, as a test I took the Ultimate Toolbox sample application SkinsDemo and simply added a LoadBarState into the CMainFrame::OnCreate and a SaveBarState into the OnClose. On starting up the application for the second time, after the toolbar state has been saved, I get the same exact assertion failure and crash.
Any ideas? I am suspecting the docking mechanisms or toolbar handling or menu handling mechanisms creating a toolbar on the fly and not destroying it before the SaveBarState is called...
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Managed to reproduce - using the VisualStudioLikeDemo. (Didn't try skinsdemo).
The 59408 (0xe810) is the id of the default menu that is set for the frame window in the WM_CREATE handler of COXMenuBarHost<PARENTWND>::WindowProc.
Defined in OXMenuBar.h as
// default ID for menubar #define AFX_IDW_MENUBAR 0xE810
On checking the registry (HKEY_CURRENT_USER\Software\Ultimate Toolbox Samples\VisualStudioLikeDemo\) I can see that an entry is added for ID 59408.
This is a bit of a nasty one to debug, needing RegEdit open to see what's going on and reset to test. (BTW if you haven't updated to Update 01 you'll probably see some text garbage here - I'd be interested to know your status on that, I'm testing with the updated code).
The COXMenuBarHost<PARENTWND>::WindowProc WM_CREATE code does seem to be creating an extra menu, after storing the main windows menu in m_hDefaultMenu, it calls SetMenu(NULL) then proceeds to create one with the default ID. Maybe something is left in the handle map that's confusing the SaveBarState and/or LoadBarState code? It does seem to leave a handle dangling.
That's as far as I've taken it - thought it might help - I don't see where SaveBarState or LoadBarState could be incrementing the count. It might be that the state.m_arrBarInfo needs to be looked at to see how it's being affected in the creation code.
Nasty - hate to post without a fix, but maybe you can get some clues from this.
Do let me know if you are using Update 01[^].
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for the quick reply! I downloaded the latest update but can't get it to build, errors in OXSkins.cpp from referencing HMONITOR: D:\UltimateToolbox\Ultimate Toolbox\source\OXSkins.cpp(4061) : error C2065: 'HMONITOR' : undeclared identifier I am running Visual C++ 6.0 with SP5 applied. We still use INI files instead of registry for our application, so it makes looking at the original toolbar problem in debug a bit easier. I did search around CodeProject and find an article which verifies the state of toolbar info here: http://www.codeproject.com/KB/toolbars/verifystateinfo.aspx[^] I adapted that code to override LoadBarState to remove any offending toolbarstate entries before calling the standard SetDockState at startup, and that gets me around this issue for now. Thought of posting that code to that article but didn't, I am still a newbie at codeproject, although a longtime lurker, this is my first thread.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Nice one - maybe you could send me that override (tim_at_codeproject.com). It might be worth providing something similar in the framework classes - or, if it's not too long, post it here.
I always wondered why none of the samples ever saved the toolbar positions... 
For the HMONITOR problem, I think you'll be ok if you add the following to your stdafx.h:
#include <multimon.h>
HMONITOR is defined in windef.h if WIN32_WINNT >= 0x0500, and multimon.h will define it for lower versions.
Thanks
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for the fix for using the latest update with my setup.
Here is the code I adapted. If you have any suggestions for making it better or bug fixes let me know.
void CMainFrame::LoadBarState(LPCTSTR lpszProfileName) { CDockState state; state.LoadState(lpszProfileName);
for (int i = 0; i < state.m_arrBarInfo.GetSize(); i++) { CControlBarInfo* pInfo = (CControlBarInfo*)state.m_arrBarInfo[i];
ASSERT(pInfo != NULL);
int nDockedCount = pInfo->m_arrBarID.GetSize(); if (nDockedCount > 0) { // dockbar
for (int j = 0; j < pInfo->m_arrBarID.GetSize(); j++) { UINT nID = (UINT) pInfo->m_arrBarID[j]; if (nID == 0) continue; // row separator
if (nID > 0xFFFF) nID &= 0xFFFF; // placeholder - get the ID
if (GetControlBar(nID) == NULL) { pInfo->m_arrBarID.RemoveAt(j--); // invalid bar ID, do not load the state } } } if (!pInfo->m_bFloating) // floating dockbars can be created later { if (GetControlBar(pInfo->m_nBarID) == NULL) { state.m_arrBarInfo.RemoveAt(i--); // invalid bar ID, do not load the state } } }
SetDockState(state);
return; }
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks - here's a formatting tip - copy from VS (I sometimes hit Edit | Advanced | Untabify selection before copy), then hit the code block thingy to get a pair of pre tags - <pre></pre> and paste into them:
void CMainFrame::LoadBarState(LPCTSTR lpszProfileName) { CDockState state; state.LoadState(lpszProfileName); for (int i = 0; i < state.m_arrBarInfo.GetSize(); i++) { CControlBarInfo* pInfo = (CControlBarInfo*)state.m_arrBarInfo[i]; ASSERT(pInfo != NULL); int nDockedCount = pInfo->m_arrBarID.GetSize(); if (nDockedCount > 0) { // dockbar for (int j = 0; j < pInfo->m_arrBarID.GetSize(); j++) { UINT nID = (UINT) pInfo->m_arrBarID[j]; if (nID == 0) continue; // row separator if (nID > 0xFFFF) nID &= 0xFFFF; // placeholder - get the ID if (GetControlBar(nID) == NULL) { pInfo->m_arrBarID.RemoveAt(j--); // invalid bar ID, do not load the state } } } if (!pInfo->m_bFloating) // floating dockbars can be created later { if (GetControlBar(pInfo->m_nBarID) == NULL) { CControlBarInfo* pCBI = (CControlBarInfo*) state.m_arrBarInfo.GetAt(i); // added TD delete pCBI; // added TD state.m_arrBarInfo.RemoveAt(i--); // invalid bar ID, do not load the state } } } SetDockState(state); return; }
et voila.
I did a quick test, and this works nice - I added two lines above before the RemoveAt call to prevent a leak.
Thanks again,
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi all,
I've moved my project to VS2008 under Vista. Thanks to the community ! All things compile fine without errors.
During runtime one problem occured with the main menu. While hovering with the mouse a blue frame appears. Ok. In case I press a menu item and the drop-down menu opens, the blue frame disappears. I've tried different Skins (XP, 2003). It is not skin dependent.
jung-kreidler
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi
I've seen this issue - it might the last to address for Vista. There may be a need for some additional code to handle this properly. I do know that I saw this problem on Vista last year, compiling with the Vista SDK kit that was released for VS2005, so it predates update 01 (which contained several of Manfreds changes to the menu and bitmap menu files).
Tricky one - and I won't be much help beyond that at the moment, as I don't have a Vista box, but thought I'd mention the above.
There seems to be another annoyance in the mix as we move toward VS2008 and Vista. I've been following the VS2008 threads, and have I think incorporated the same changes (wrapped in checks for _MFC_VER so as not to break on earlier compilers).
Working with VS2008, no service pack, no MFC feature pack, on XP Pro SP 2.
I've noticed that WINVER 0x0600 incorporates an additional param in the NONCLIENTMETRICS struct, iPaddedBorderWidth. This means that calls to SystemParametersInfo to populate this struct will fail on XP if the code was compiled for Vista, as sizeof(NONCLIENTMETRICS) will give the wrong result.
There are several places in the UT code where this call is made to retrieve the font to be used for menus, tabs, etc. Many of these fail silently, resulting in either incorrect fonts or no fonts at all if the app was compiled for WINVER >= 0x0600 and run on XP Sp2 (Ox0502).
So, at present, it seems that some of the toolbox classes will not deploy properly on XP if compiled for Vista, even with the changes requred for _MFC_VER 0x0800. Many of the samples need to define WINVER 0x502 to run properly on XP SP2 when compiled with VS2008.
I may be missing something here, but this seems < optimal. It looks like folks might need to maintain separate Vista/XP builds unless there's a reasonable way to figure this out at runtime.
I would imagine #define WINVER 0x0502 at the start of your apps stdafx.h would result in problems on Vista. Might be worth a try, as there could be provision in the SystemParametersInfo code to handle this for legacy apps.
I don't think it will fix the menubar issue - would be sweet if it did - but if things at least run properly that might help move toward a baseline target OS - if the menu fix involves some new usage of a WINVER 0x600 api, then we're back to runtime checks, but that should be easier than the NONCLIENTMETRICS issue.
This of course wouldn't address problems with apps using the UT code that are specifically targeting Vista APIs, but they might not be targeted at XP, and I'm more concerned with providing a documented baseline deployment target for the kit itself.
Should also mention the issue mentioned by HRS23 re WINVER 0x0500 - seems to be getting more difficult to target multiple platforms.
Thoughts? Anyone? I really have the feeling I'm either missing something, or maybe I'm making too much of this - just trying to sort out the issues.
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
I've feared that I do not get a fix for this. So I'll try to fix it on my own... hoping that I don't get nuts with my small brain...
Actually my WINVER is set to 0x501, since my app has to run on both OS (lucky that I do not have to deal with W2k any more). I've tried to run with 0x600, but there is no difference. Maybe the skinning part fails. MS has changed a lot of things according to the com dialogs, where it is not possible to get the OS look'n'feel on both OS with the same code. E.g. the CFileDialog of the new MFC has got functions, which are present on Vista, only. One has to deal with the LoadLibrary stuff, but this is hard work. Ok, stop the lots of blahblah.
Due to the menu issue, can you tell me where to put the leverage? At the moment I'm digging in the dark.
jung-kreidler
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi
For the menu issue, I _think_ I'd start looking at the DrawItem code for each of the toolbar skins classes (COXToolbarSkinClassic, COXToolBarSkinXP, and COXToolBarSkin2003).
Each of the respective DrawItem methods was modified by Manfred and should have this change:
// v9.3 update 01 modification Manfred Drasch - for drawing in Vista if(pCoolToolbar->IsKindOf(RUNTIME_CLASS(COXMenuBar))) { COXMenuBar* pMenuBar=DYNAMIC_DOWNCAST(COXMenuBar,pCoolToolbar); if(pMenuBar!=NULL) { if(bSelected) bHot = (pMenuBar->m_nActiveMenuItem == pCoolToolbar->CommandToIndex(pTBB->idCommand)); } } // end modification Manfred Drasch
I think the intent here is if this is the item on the toolbar, there is a bit extra needed to flag it as a hot item needing the special background when running on Vista.
So, I guess I'd start with a break here, and do some tracing. I would've thought he'd nailed it - perhaps some extra attention needed farther along - are you testing with/without aero?
On the other front, nice to know that Vista handles the legacy SystemParametersInfo calls properly - perhaps we could place #pragma message alerts in the affected files to warn if compiling for Vista that XP deployments will have problems.
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Have had some breakpoints here in Drawitem, which calls DrawItemBackground. But it draws only a light blue background with a darker blue frame and a white text.
After adding the fix of Manfred the item showed up, but still with another look. Then I've tried on XP, which gave the same result (blue frame) and no white frame with shadow. So I removed Manfreds fix and stepped through the code in DrawItem. In line 8130 there is a dc.BitBlt(blah), which showed the same blue frame. After pressing F5 the menu item has been painted correctly. Mmmh, somewhere else there is code which paints the XP-theme main menu items.
This is what I've found: In OXBitmapMenu there is a shadow window constructed: BOOL COXBitmapMenu::TrackPopupMenu(COXCoolToolBar* pCoolToolBar, CWnd* pWnd, LPCRECT lpRect) ... COXShadowedItemWnd* pSIW = new COXShadowedItemWnd(pCoolToolBar, iSelectedItem, nPosFlags); ... This window is used to paint the frame and the shadow. The paint-routine in OXSkins.cpp:
void COXMenuSkinXP::OnPaintShadowedItemWnd(COXShadowedItemWnd* pShadowedItemWnd)
paints the frame and the shadow, at least on XP. In XP the dc.LineTo(...) show an immediate result, while stepping through the code. On Vista nothing happens. Don't know why...
Yes, this is the Aero theme.
jung-kreidler
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Well, first my bad for not reaizing that you we're not using update 01 - we're working with different code here. If you want to back up what you have, and install update 01[^], I'll be happy to send you what I have for the VS2008 mods (email me) so as to avoid redoing your changes.
Not essential, as the problem might persist, but might be worth a sync.
Here's the extent of what I can glean about certain DC ops under Vista. With the Aero stuff turned on, the DWM[^] comes into play.
The first issue here is that GetPixel/SetPixel and LineTo will run more slowly in this environment. This is especially true if these calls are made with a screen DC - the code in DrawMenuItemShadow was rewirtten to use a memory based DC for this reason - it was incredibly slow (looked like a hang) without this mod. For a window based DC, the problem is (reportedly) not as noticable, but a popup menu may often extend past the boundaries of it's parent window, so a screen DC necessary here.
The LineTo calls you refer to are also made to a CPaintDC, rather than a CWindowDC or CClientDC. That may have an impact - you could experiment with a CWindowDC (just temporarily for the LineTo - a screen DC should still be passed to DrawMenuItemShadow).
It's aslo possible that the LineTo calls might benefit from blitting - the code changes that revised DrawMenuItemShadow were just intended to get past the worst of the Get/SetPixel problem - not a complete fix, and the issue was one of speed, not a complete no show.
Keep in mind the possiblity that there may still be video cards that may not yet have the new driver model (LDDM/WDDM Longhorn/Windows Display Driver Model) properly implemented (comments on this topic seem to imply that some cards handle LineTo better than others, from a speed standpoint in any case).
But I'm inclined to think that with the incorporation of Manfred's changes (update 01 contains the above mentioned and a few others that stabilize the menuing code) and possibly a rethink of the OnPaintShadowedItemWnd code things should be good.
Do the LineTo calls show up with Aero turned off?
Tim
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Thanks for the '01' patch. I've Merged all the stuff into mine.
All color schemes (Windows Vista-Basic, Windows-Standard, Windows-classic), but Aero-Glass, work. The menus show up with a white background and the shadow.
Setting up for DWM is another task, because in that case the DWM lib (or functions) had to be added with the LoadLibrary-stuff, depending on the OS... Seems to be that I'm stuck.
I've added some code to determine whether the Aero-Glass theme is enabled. Please send me an email adress, since I can't add zip-files like you do, or send me a mail to franz-dot-reitner-at-pco-dot-de (replace -dot- with . and -at- with @). I'll send you the code to check for the DWM manager.
Having this information I changed the following line (added gl_bIsDWMEnabled): ... // v9.3 update 01 modification Manfred Drasch - for drawing in Vista if((gl_bIsDWMEnabled && pCoolToolbar->IsKindOf(RUNTIME_CLASS(COXMenuBar)))) ... gl_bIsDWMEnabled is global at the moment.
I recognized that there is no need to paint the XP-Item here, since it is overpainted by the ShadowWindow call. So I added this to the 'hot-selected' case: ... else if (bSelected && bHot) { if(!gl_bIsDWMEnabled) return; // Selected and hot ...
This works now on Vista (all styles) and XP. ...and it looks the same as Visual Studio. It seems MS has got the same problems while skinning their apps .
Thanks Tim, for your support!
jung-kreidler
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
Hi Tim, There are a lot of TEXT("?) errors when I build the statical lib project in vc6.0. I didn't change the .cpp file. I don't know how it happens.
OXHTMLParser.cpp { TEXT("nbsp"), TEXT("?), }, { TEXT("cent"), TEXT("?), }, { TEXT("pound"), TEXT("?), }, { TEXT("copy"), TEXT("?), }, { TEXT("reg"), TEXT("?), },
OXParser.cpp
ParserEntity COXParser::m_Entity[] = {
{TEXT("gt"), TEXT(">")}, {TEXT("lt"), TEXT("<")}, {TEXT("amp"), TEXT("&")}, {TEXT("apos"), TEXT("\'")}, {TEXT("quot"), TEXT("\"")},
{TEXT("quot"), TEXT("\"")}, {TEXT("amp"), TEXT("&")}, {TEXT("apos"), TEXT("\'")}, {TEXT("lt"), TEXT("<")}, {TEXT("gt"), TEXT(">")}, {TEXT("nbsp"), TEXT(" ")}, {TEXT("iexcl"), TEXT("?)}, {TEXT("cent"), TEXT("?)}, {TEXT("pound"), TEXT("?)}, {TEXT("curren"), TEXT("?)}, {TEXT("yen"), TEXT("?)}, {TEXT("brvbar"), TEXT("?)}, {TEXT("sect"), TEXT("?)}, {TEXT("uml"), TEXT("?)}, {TEXT("copy"), TEXT("?)}, {TEXT("ordf"), TEXT("?)}, {TEXT("laquo"), TEXT("?)}, {TEXT("not"), TEXT("?)}, {TEXT("shy"), TEXT("?)}, {TEXT("reg"), TEXT("?)}, {TEXT("macr"), TEXT("?)}, {TEXT("deg"), TEXT("?)}, {TEXT("plusmn"), TEXT("?)}, {TEXT("sup2"), TEXT("?)}, {TEXT("sup3"), TEXT("?)}, {TEXT("acute"), TEXT("?)}, {TEXT("micro"), TEXT("?)}, {TEXT("para"), TEXT("?)}, {TEXT("middot"), TEXT("?)}, {TEXT("cedil"), TEXT("?)}, {TEXT("sup1"), TEXT("?)}, {TEXT("ordm"), TEXT("?)}, {TEXT("raquo"), TEXT("?)}, {TEXT("frac14"), TEXT("?)}, {TEXT("frac12"), TEXT("?)}, {TEXT("frac34"), TEXT("?)}, {TEXT("iquest"), TEXT("?)}, {TEXT("Agrave"), TEXT("?)}, {TEXT("Aacute"), TEXT("?)}, {TEXT("Acirc"), TEXT("?)}, {TEXT("Atilde"), TEXT("?)}, {TEXT("Auml"), TEXT("?)}, {TEXT("Aring"), TEXT("?)}, {TEXT("AElig"), TEXT("?)}, {TEXT("Ccedil"), TEXT("?)}, {TEXT("Egrave"), TEXT("?)}, {TEXT("Eacute"), TEXT("?)}, {TEXT("Ecirc"), TEXT("?)}, {TEXT("Euml"), TEXT("?)}, {TEXT("Igrave"), TEXT("?)}, {TEXT("Iacute"), TEXT("?)}, | | | | | |