|
|
Comments and Discussions
|
|
 |
|
|
I'm converting an old VS6++ project to VS2010 and I upgraded to the latest version of Ultimate Toolbox since the old one used in VS6++ didn't work at all. I have got so far so that everything compiles, but it can't build it since it says 1>LINK : fatal error LNK1104: cannot open file 'UTLibStaticD.lib'
I can't find any file named that in the lib folders. I have tried to rebuild everything in the lib folders but all it does is creating UTStaticLib.lib so it's not the same file.
It is the reference to this file in UTStaticLib.h that gives the error in VS2010
What should I do?
EDIT: I found the problem. I hadn't built the libraries for release, only for debug so after I built it for all ouputs, it works.
modified 11 Apr '13 - 9:07.
|
|
|
|
|
Hi.
I want to use COXTreeCtrl with single selection functionality. But set/unset TVOXS_MULTISEL style has no effect. You can see it in ExtTreeDemo too. Clear TVOXS_MULTISEL checkbox and it is still possible to select more than one row (hold Ctrl or Shift and click another row).
It is possible to exact single selection functionality?
|
|
|
|
|
Im using tool box for my MDI application all works fine but i have one problem..
I used TabView for MDI to show all view in tab.
But i also want to display a tooltip text when my mouse is on tab so that user can easily see information about that view..
please tell me how to display tool tip text on TABVIEW In tool box.
thanks..
modified 25 Jul '12 - 1:27.
|
|
|
|
|
I think I have been through everything carefully (directories, Comments and Problems, Help files) but I can't find COXCommandLine files. I find a description in the Help file but none of the files nor the sample suggested by the Help. Did I miss something about the removal of those files?
I just downloaded everything today and applied the updates.
From the help (I find none of these):
SOURCE
OXCmdLEx.cpp
OXCmdLne.cpp
OXCmdOpd.cpp
OXCMDOpt.cpp
INCLUDE
OXCMDOpt.h
SAMPLE
\Samples\Utility\cmdnln\cmdln.dsp
|
|
|
|
|
The source files should be in the Archive directory, which, oddly enough, is bundled with the samples zip. I don't think the sample survived tho.
|
|
|
|
|
The sample did not survive. Pity.
Oddly, I had gone through the archive before I posted. I looked right at the files apparently and couldn't see them.
Thanks
|
|
|
|
|
there're many compile error like this:
OXParser.cpp(84) : error C2001: newline in constant
and then in cpp file I found(BOLD):
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("?)},
what's this problem?
|
|
|
|
|
We've seen this before I think - it has something to do with compiling on machines set for certain multibyte Chinese(?) language settings - (I think) - search this forum for threads on this. Iirc the workaround is to switch over to another language to compile the libs - might be nice to find an actual fix.
|
|
|
|
|
you can fix this issue by any one of the following ways(the 1st is recommanded):
1.compile in english environment
2.convert
OXHTMLParser.cpp
OXParser.cpp
OXPhysicalEditEx.cpp
OXQuickString.cpp
and WABTAGS.H in vc6 include directory
to utf8 coded file
3.change language setting for chinese windows
FYI
modified 10 May '12 - 11:51.
|
|
|
|
|
|
I have a small example I have developed that demonstrates the correct use of the COXShortcutBar class. It works very well indeed. When I move this code into my much larger application I experience a stack overflow. I have traced the problem to the ::CreateWindowEx procedure call well inside the Create method of COXShortcutBar. When I click F11 on the debugger, a Stack Overflow message is displayed and the debugger execution point is moved to point at the BEGIN_MESSAGE_MAP for the COXShortcutBar class.
What have I done to deserve this? How do I address this problem?
Any sage comments gratefully received.
|
|
|
|
|
Er, I think the message queue can overflow with, say, unhandled paint messages or perhaps a WM_PAINT generating a WM_PAINT? Since this is happening in the WM_CREATE handler not sure how much use something like Spy++ will be - but I'd suggest thinking in terms of a problem of some kind with the message queue.
What's the relationship of the shortcut bar to the other app windows? Maybe something not getting routed properly?
|
|
|
|
|
I have now had the opportunity to examine both apps with SPY++.
The smaller demo app has the WM_TIMER message being generated by OXShortcutBar continuously. The larger target app has no messages being displayed by SPY++. THe larger target app is totally non-timer event driven. There are no WM_PAINT messages to be seen.
Why is OXShortcutBar generating WM_TIMER events? It would seem the WM_TIMER messages are the culprets.
|
|
|
|
|
Several of the toolbox classes generate WM_TIMER events to check for mouse locations, drop situations etc. They implement their own OnTimer handlers, which should take care of things.
In the shortcut bar the main SetTimer call is in InitShortcutBar, called from Create. Break there to check. Looks like a half second interval. Is it possible that for some reason the WM_TIMER messages aren't routed correctly? Suspect a break in COXShortcutBar::OnTimer wouldn't get hit, if it is the WM_TIMER causing problems. A trace through the whole Create chain might be useful.
|
|
|
|
|
Hi,
i've add an image background to COXTaskPanel by event OnPaint().
This is the code (userbmp is the pointer of image backgound - usercolor is an RGB color, user defined, used to draw uniform background).
void COXTaskPanel::OnPaint()
{
CPaintDC dc(this);
int yPos = (GetWindowLong(m_hWnd, GWL_STYLE) & WS_VSCROLL) ? GetScrollPos(SB_VERT) : 0;
dc.SetWindowOrg(0, yPos);
CRect rect;
GetClientRect(&rect);
rect.bottom += yPos;
CDC memdc;
memdc.CreateCompatibleDC(&dc);
CBitmap* pOldBitmap;
CBitmap bmap;
if (userbmp != NULL)
{
userbmp->SetBitmapDimension(rect.Width(), rect.Height());
pOldBitmap = memdc.SelectObject(userbmp);
}
else
{
bmap.CreateCompatibleBitmap(&dc, rect.Width(), rect.Height());
pOldBitmap = memdc.SelectObject(&bmap);
}
if (userbmp == NULL)
{
if (userbgcolor == -10)
if(COXTaskPanel::IsThemed())
G_DrawThemeBackground(m_hTheme, memdc.m_hDC, 1, 0,rect, NULL);
else
memdc.FillSolidRect(rect, GetSysColor(COLOR_WINDOW));
else
memdc.FillSolidRect(rect, userbgcolor);
}
DrawGroups(memdc.m_hDC);
dc.BitBlt(0, 0, rect.Width(), rect.Height(), &memdc, 0, 0, SRCCOPY);
memdc.SelectObject(pOldBitmap);
}
When I start the application it's all ok. I open a group item and it's ok too. When I close the group item I obtain a not correct refresh of the form. Can you help me to understand where must I modify the code to do the correct refresh of image background?
10x
Sandro
|
|
|
|
|
Hello.
I can't install the toolbox 
I have extracted the ZIP files and startet with building "Ultimate Toolbox\lib\JPEG\jpg.dsw"
Then I startet to build "Ultimate Toolbox\lib\JPEG\..." , "Ultimate Toolbox\lib\Build Libs".
Everything went fine.
But when I tried to build "Ultimate Toolbox\lib\Build DLLs" I got the error:
LINK : fatal error LNK1181: Eingabedatei "..\..\Lib\libs\jpgr.lib" kann nicht geoeffnet werden
In this directory I have the file with the name jpgru.lib but not jpgr.lib.
And now I don't know how to continue... please help.
blackxx
|
|
|
|
|
Looks like you didn't build all the jpeg lib configurations (ru is release Unicode, r is release non-Unicode, etc) - open the jpeg project again and do a batch build - should do it.
|
|
|
|
|
|
That might be the result of some reference to mfc42u.lib buried either in the BuildDLL project file or the jpeg project file - you miight need to manually edit that out. Not sure on this one.
There are some known issues with the project files under VS2010, mostly with the relative file paths used - some folks here have been able to recreate the projects without too much hassle, but I don't think anything's been updated. Code wise should be ok, though I haven't tested much myself.
Is it outdated? Well, I grabbed a couple of classes for I project I worked on last month - but then I'm a bit of a dinosaur 
Cheers
Tim
|
|
|
|
|
Thanks for your help Tim 
|
|
|
|
|
By chance I've got a warning:
c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\afxmenubar.h(30) : warning C4005: 'AFX_IDW_MENUBAR' : macro redefinition
...blah...\include\oxmenubar.h(139) : see previous definition of 'AFX_IDW_MENUBAR'
afxmenubar.h:
#define AFX_IDW_MENUBAR 0xE806 // CMFCMenuBar
oxmenubar.h:
#define AFX_IDW_MENUBAR 0xE810
The problem came up after adding CMFCPropertyGridCtrl object to the application.
I've changed the order of header files to fix this warning, but after that I get an assertion in dockstat.cpp at SetDockState line 492 (ASSERT(pInfo->m_pBar!=NULL)) the first time the app starts with 'old saved state'.
pInfo->m_pBar = GetControlBar(pInfo->m_nBarID);
ASSERT(pInfo->m_pBar != NULL); //toolbar id's probably changed
m_nBarID is 0xE810, which is the ox define.
I think the problem is that the defines do not match. Up to now my app worked with ox define 0xE810, but after changing the header file order the mfc define 0xE806 is used. GetControlBar does not find this ID since 0xE810 is saved in and reloaded from the registry.
The ox define should be fixed, which in turn leads to an assertion.
...hmm, any thoughts how to get out of this.
|
|
|
|
|
|
Yes, there is a define in 05, but in case the header file order includes ox stuff first, it'll be defined as 0xE810 (ox), which leads to the warning. afxmenubar.h does not contain an #ifndef AFX_IDW_MENUBAR guard.
In case it is defined after afx stuff it will be defined as 0xE806 (afx), which leads to the assert. Ok, this is only in debug mode and should not cause an app crash, but the menu toolbar will be moved below the other toolbars since no position info is available.
However, I do not understand why it is defined different.
|
|
|
|
|
jung-kreidler wrote: However, I do not understand why it is defined different.
Nor do I - it may be a quirk left over from VC6 days.
If I read you correctly removing the defines leaves the problem of the orphaned ID persisting in the registry, a problem if you have deployed apps - there's some code here[^] that I think might address that, though admittedly a bit of a hack.
Odd. As I type this I'm not sure I've completely grasped it - and you're right, I think, in that understanding the reason for that define would be helpful - my best guess is that someone wanted to make sure it was visible to the unit at compile time, and that over the years it was re def'd in afxmenubar.h.
Tim
|
|
|
|
|
|
|
 General  News  Suggestion  Question  Bug  Answer  Joke  Rant  Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.
|
The Ultimate Toolbox is now Open Source
| Type | Article |
| Licence | CPOL |
| First Posted | 24 Aug 2007 |
| Views | 1,654,733 |
| Downloads | 45,048 |
| Bookmarked | 414 times |
|
|
Submit an article or tip
Post your Blog
![Rose | [Rose]](/script/Forums/Images/rose.gif)
