|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|