|
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:
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));
}
}
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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("?)},
{TEXT("Icirc"), TEXT("?)},
{TEXT("Iuml"), TEXT("?)},
{TEXT("ETH"), TEXT("?)},
{TEXT("Ntilde"), TEXT("?)},
{TEXT("Ograve"), TEXT("?)},
{TEXT("Oacute"), TEXT("?)},
{TEXT("Ocirc"), TEXT("?)},
{TEXT("Otilde"), TEXT("?)},
{TEXT("Ouml"), TEXT("?)},
{TEXT("times"), TEXT("?)},
{TEXT("Oslash"), TEXT("?)},
{TEXT("Ugrave"), TEXT("?)},
{TEXT("Uacute"), TEXT("?)},
{TEXT("Ucirc"), TEXT("?)},
{TEXT("Uuml"), TEXT("?)},
{TEXT("Yacute"), TEXT("?)},
{TEXT("THORN"), TEXT("?)},
{TEXT("szlig"), 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("?)},
{TEXT("icirc"), TEXT("?)},
{TEXT("iuml"), TEXT("?)},
{TEXT("eth"), TEXT("?)},
{TEXT("ntilde"), TEXT("?)},
{TEXT("ograve"), TEXT("?)},
{TEXT("oacute"), TEXT("?)},
{TEXT("ocirc"), TEXT("?)},
{TEXT("otilde"), TEXT("?)},
{TEXT("ouml"), TEXT("?)},
{TEXT("divide"), TEXT("?)},
{TEXT("oslash"), TEXT("?)},
{TEXT("ugrave"), TEXT("?)},
{TEXT("uacute"), TEXT("?)},
{TEXT("ucirc"), TEXT("?)},
{TEXT("uuml"), TEXT("?)},
{TEXT("yacute"), TEXT("?)},
{TEXT("thorn"), TEXT("?)},
{TEXT("yuml"), TEXT("")},
OXPhysicalEditEx.cpp
LPCTSTR COXLengthEdit::m_rgpszLengthUnitNames[] =
{
_T("km"), // OX_LENGTH_KILOMETER
_T("m"), // OX_LENGTH_METER
_T("dm"), // OX_LENGTH_DECIMETER
_T("cm"), // OX_LENGTH_CENTIMETER
_T("mm"), // OX_LENGTH_MILLIMETER
_T("祄"), // OX_LENGTH_MICROMETER
_T("nm"), // OX_LENGTH_NANOMETER
_T("?), // OX_LENGTH_ANGSTROM
_T("\""), // OX_LENGTH_INCH
_T("pt"), // OX_LENGTH_POINT
};
LPCTSTR COXAngleEdit::m_rgpszAngleUnitNames[] =
{
_T("?),
_T("rd"),
_T("grad"),
_T("deg"),
_T("rad"),
};
OXQuickString.cpp
BOOL COXQuickString::Strip()
{
const TCHAR chNBSP = TEXT('?); // This is character 160, NOT character 32
if (IsEmpty())
return TRUE;
modified on Friday, July 11, 2008 11:28 PM
|
|
|
|
|
Yes - I think you'll find that if you change your regional settings from Chinese or Korean to western settings the lib will build - then you can change back and use the lib.
Tim
|
|
|
|
|
Tim, thank you very much for helping me!
modified on Saturday, July 12, 2008 9:49 PM
|
|
|
|
|
You're welcome
It would be nice to find a fix for this - hopefully someone will. I'm not sure what causes those macros to foul up on some systems.
Tim
|
|
|
|
|
Hi, Tim.
Excuse me. I met the same problem as jiangbing. But my regional settings are Chinese all the time and I have never changed it. I tried Chinese and western settings but the problem still existed.
I changed the settings from the [Control Pannel]->[Regin and language]. Is it right? I still tried to set language in VC6.0 but it hae no effect.
If you have any time, would you please help me for more details? Thanks a lot.
Best regards.
Delia
|
|
|
|
|
|
Hi Delina
I wonder if you could try something here - there seem to be only a few files that cause problems:
OXQuickString.cpp
OXPhysicalEditEx.cpp
OXParser.cpp
OXHTMLParser.cpp
Could you try opening these in Notepad - if they appear ok, try saving them as Unicode (you'll see a droplist of options in the Save As... dialog).
If the characters appear odd in Notepad (as in jiangbing's post) then try switching to western regional settings (yes, control panel) and reloading before saving.
See if that helps compilation - would like to know.
Thanks
Tim
|
|
|
|
|
Hi Tim,
I'm very sorry to reply your message so late. I had a business trip and came back yesterday. I'm able to compile the source code successfully as you suggested.
Thank you very much.
Delina
|
|
|
|
|
I tried changing the child window style, but evey combination I have found that removes the x in the corner also removes the title from the document tab.
The intent is to have a program with mutliple tabbed documents that only close when the program shuts down. no X in frame corner and file save/close over ridden in the menus.
|
|
|
|
|
This is inherently messy, I think - you end up battling the framework on too many fronts.
One tack I've seen tried in the past is to use EnableMenuItem to disable the close item - once done (trick in itself, for the tabclientwnd) the X appears greyed when the window is not maximized, but when maximized in the parent frame window the x is enabled again - I know of no way of getting to that one (of course, the overrides can stop the close, but looks bad).
Possible design options: 1. use an SDI with a form view, and embed a COX3DTabViewContainer in the view (should be doable), or 2. use a COX3DTabViewContainer on a dialog (definitely doable - see the FAQ samples).
Tim
|
|
|
|
|
Hi,
i'm working now for some days with the ultimate toolbox.
The small examples were no problem, but now i'm in the advanced folder at the Fileexplorer example.
This is the contol i need and the reason for me to start with the UT because later on i wlii try to implement such a treevew and its listview in a projekt of mine.
But because of the total lack of tuts dealing with the UT i've now a problem.
I copied the FileExplorer sample out of the sample folder in another folder and then i added the headerfiles OXShellFolderTree.h, OXShellNamespaceNavigator.h und OXShellObjectList.h to the project, it works !
But know i want to build up this FileExplorer example on my own, because of training reasons.
I opend a new mfc project (Windows Explorer Style) and added the headerfiles.
What have i to do now?
There is a folder in the orig. sample "UTBSource", have i to add it to my project too?
Have i to change something in the project settings in the studio?
Oh i think it is quiet important, i'm usin Vc++ 6.0 !!!
Thanks a lot for your help!
Best regards
Crocodile Buck
P.S.: Do you know some step by step tuts dealing with the UT.
P.P.S.:Sry for the crosspost but i realized not, that the other post was in the wrong article
|
|
|
|
|
Hi
Sorry for the slow response - was travelling.
Yes, you'll need to add the .cpp files for the UTSource items as in the sample. Or, link with either the static lib or DLL (you'll find tutorials on this in the chm doc file).
You'll probably need to add the Ultimate Toolbox\Include dir as an additional include dir in your project settings as well.
But, seeing as I'm a bit late with this response, I'd guess you have already made some of these changes - let me know what your current status is and I'll try to be a bit more prompt in replying
Cheers
Tim
|
|
|
|
|
Hi
I recently had to compile the Ultimate Toolbox for VS2008. Although we internally use a modified 9.0 versions, some of my fixes might still help those who need to compile for VS2008 right now.
Here are my fixes:
1. Fixed compiler error (caused in OXCoolToolBar.h) 'error C2059: syntax error : '<L_TYPE_raw>'' in src\mfc\afximpl.h. It turned out that WinUser.h has the definition
#if(_WIN32_WINNT >= 0x0501)
DECLARE_HANDLE(HRAWINPUT);
...
#endif
and we define _WIN32_WINNT to be 0x0500 in our code. We could have set _WIN32_WINNT to 0x0501 (WinXP) and no longer support Win2K, but I found out that I can simply add the following lines in our StdAfx.h before including any toolbox header file (or afximpl.h):
//HRS: Some UltimateToolbox files include afximpl.h which creates compiler errors "syntax error : '<L_TYPE_raw>'" because HRAWINPUT is not defined if _WIN32_WINNT < 0x0501 in VS2008
#if (_WIN32_WINNT < 0x0501)
DECLARE_HANDLE(HRAWINPUT);
#endif
--> This fixes the problem and I think it is safe since the toolbox doesn't seem to use anything related to HRAWINPUT.
See also: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=277982
http://blog.m-ri.de/index.php/2007/05/21/atl-unter-orcas-arbeitet-nur-mit-winver0x0501-dh-xp/
2. Fixed compiler error 'macro redefinition' in \UltimateToolbox\OXTreeCtrl.h (line 530) by changing
#define TVGN_NEXTSELECTED 0x31
to
#define TVGN_NEXTSELECTED 0x000B //0x31 //HRS: Clashed with definition in CommCtrl.h
--> This now matches the new definition in CommCtrl.h (line 5555). I didn't see any place where the extended GetNextItem codes get tested to be in a certain range. So this change should probably cause no problem. Otherwise we could simply rename TVGN_NEXTSELECTED to something like TVGN_NEXT_SELECTED, but then we should probably rename the other defines as well.
3. Fixed compiler error 'overriding virtual function return type differs and is not covariant from 'CWnd::GetMenu'' in \UltimateToolbox\oxmenubar.h (line 311) by changing
HMENU GetMenu() const {
to
HMENU GetHMenu() const {
--> Since the MFC function CWnd::GetMenu returns a type CMenu* instead of HMENU, I simply changed the function name (and where it's being called in the toolbox) to avoid compiler errors.
4. Fixed compiler error in \UltimateToolbox\OX3DTabView.cpp (line 389).
DWORD dwStyle=AFX_WS_DEFAULT_VIEW;
//HRS: bWin95 is no longer a member of AUX_DATA. Since our product only support Win2k or later it is safe to assume bWin95==0
//if(!afxData.bWin95)
//{
dwStyle&=~WS_BORDER;
//}
|
|
|
|
|
Hello!
I'm just trying to use a COXTreeCtrl within an MDI application in a CFormView (VS2005).
Compiling in debug mode causes some LNK4204 linker warnings. Unfortunately, on running the compiled program, there is an assertion, which I can't understand:
"Condition: ASSERT( m_sToday.LoadStringA(26854) );
Program :\Projects\Appl\EOSParEdit\Test\TestProjekt\Src\debug\EOSParEdit.exe
File: d:\projects\libs\ultimatetoolbox\source\oxcalendarpopup.cpp
Line: 85"
What is really strange: the file d:\projects\libs\ultimatetoolbox\source\oxcalendarpopup.cpp does not exist on my HD and I don't use OXCalendarPopup in my program.
I hope, somebody can help me. Otherwise I will not be able to use COXTreeCtrl in my project. And that would really be a pity.
Thanks,
Tanja
|
|
|
|
|
Hi Tanja
Items in the tree control can be set to invoke a calendar control on edit, using SetEditMode, if OXET_CALENDAR is specified for SetEditMode.
The calendar popup will try to load strings from a resource string table which probably isn't avaiable here.
You could try adding the OXMain.rc file to the resource compile time directives of your project - see the doc's on Linking To the Ultimate Toolbox on how to do this - that should make the string available.
I'm not sure about the odd filename - how are you linking to the Toolbox? It sort of looks like you are linking to a debug lib that was built on another machine.
Tim
|
|
|
|
|
Hi Tim,
first of all: thank you for your help. Now it almost works. You are right: I do link to a debug lib that was built on another machine. We have some lib-folder on a server where all our used libs are located and we are working with them using an environment variable. Till now, I'm statically linking to the UTLibSharedD.lib. Would dynamically linking be the better way?
Actually, I now have another problem. At starting my application, everything works fine, but when I close it (or when I close the child frame, where the COXTreeCtrl is used), there is a heap corruption debug error ("CRT detected that the apllication wrote to memory after end of heap buffer"). The apllication is a VS2005 Standard MDI application and therefore works with DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE macros. Can this be a problem? (You see: I'm not very experienced on such topics... actually, this is my first MDI application and I'm tairing my hair on fighting with it )
Tanja
|
|
|
|
|
Two thoughts here,
One, using a COXTreeCtrl in a CView might be a bit tricky - it could be something to do with the way the control is created and destroyed, which would be something to look at.
Two, are you using the latest version of the UltiateToolbox code? I have seen heap corruption occur in toolbox code, though the context of the bitmap menus. I think these were addressed in the 9.3 release, and Update 01 [^] has further fixes in this area.
If the libs on the server are not built with v9.3 with the update applied, I'd try ensuring that first - you can test on your own machine bypassing the libs on the server.
If you are using the latest, and you have a small SDI project that could demo the error you could send it to me at tim _at_ codeproject.com - maybe I can spot something.
I don't think you should need to touch the IMPLEMENT_DYNAMIC macro unless you are deriving a class from COXTreeCtrl.
Tim
|
|
|
|
|
Hi Tim!
please excuse the delay. I'm in paternity leave, so I'm not working on my project every day.
After the update of the lib with your Update 01, the error does no longer occur. So, thank you very much for your support!
Unfortunately, there is a new problem with the control:
Although I set an item (e.g. a subitem) to editable (SetPlainEditMode), it actually is not editable.
Must I set set something else to make items editable?
Best regards, Tanja
|
|
|
|
|
Hi Tanja,
I've got the same problem... I took the ExtendedTreeControl as pattern, set the edit mode of a subitem to OXET_COMBO, but nothing happens. The cell of the subitem is still not editable.
m_treeCtrl.SetSubItem(hItem,2,OX_SUBITEM_TEXT,szItems[nIndex*6+2]);
m_treeCtrl.SetEditMode(hItem,OXET_COMBO,arrPosition,2);
The sample in CodeProjekt works very well so I just copied the whole stuff in my solution without any success...
Did you find a way or the problem in your solution to set cells editable?
Regards,
Matthias
|
|
|
|
|
I've solved the Problem...
You have to set the property "Edit Labels" to true...
|
|
|
|
|
CMyView.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const COXSkinnedApp::classCOXSkinnedApp" (?classCOXSkinnedApp@COXSkinnedApp@@2UCRuntimeClass@@B)
MainFrm.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const COXSizableMiniDockFrameWnd::classCOXSizableMiniDockFrameWnd" (?classCOXSizableMiniDockFrameWnd@COXSizableMiniDockFrameWnd@@2UCRuntimeClass@@B)
MainFrm.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const COXMenuBar::classCOXMenuBar" (?classCOXMenuBar@COXMenuBar@@2UCRuntimeClass@@B)
I have make a sample which dynamically links to the Ultimate ToolBox, and it works properly. While I apply the dll to a former project, I get the above results.
Please give me some comments.
Charles
|
|
|
|
|