|
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
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
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
#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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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;
}
|
|
|
|
|
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)
{
for (int j = 0; j < pInfo->m_arrBarID.GetSize(); j++)
{
UINT nID = (UINT) pInfo->m_arrBarID[j];
if (nID == 0) continue;
if (nID > 0xFFFF)
nID &= 0xFFFF;
if (GetControlBar(nID) == NULL)
{
pInfo->m_arrBarID.RemoveAt(j--);
}
}
}
if (!pInfo->m_bFloating)
{
if (GetControlBar(pInfo->m_nBarID) == NULL)
{
CControlBarInfo* pCBI = (CControlBarInfo*) state.m_arrBarInfo.GetAt(i);
delete pCBI;
state.m_arrBarInfo.RemoveAt(i--);
}
}
}
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|