|
I got similar errors when moving from 2003 to 2010 recently. The cause was a static library that was part of my project that bound the runtime library statically rather than dynamically. For some reason this was never a problem before, but VS 2010 didn't like it.
My advice is check the libs that are part of your solution and make sure they all use the same settings regarding the runtime library being used. note that it doesn't matter whether the lib is bound statically or dynamically to your executable - the main point is that all libs must use the same version of the runtime library. (and I believe the same is true for the choice of MFC library)
|
|
|
|
|
|
Was the libcmt.lib problem : in project settings, link, input, I ignore libcmt library and goes almoust fine ... I set manually manifest.xml, and didn't like it to VS2008.
|
|
|
|
|
<< VS2008 professional edition >>
If I use precompiled header "stdafx.h", sometimes debugging just doesn't work well, some of the variable value don't show up. Then I turned off using precompiled file, everything gets back to normal.It's only my prolbem? or does it ever happen to you, could there be a solution ?
|
|
|
|
|
This is most unlikely; what is more likely is that you have some old information in your .PCH file (or in stdafx.h) that is causing the problem. Try doing a CLEAN and rebuild and check again what is happening. It would be useful to look closely at exactly what just doesn't work well and give specific details if it happens again.
The best things in life are not things.
|
|
|
|
|
Thanks for reply, I thihnk you're right.
Although it was the variables that from my cpp file didn't show up and leave the poor blue-cube(stands for variable)lonely there, I still believe it's my stdafx.h going awry.
here's my stdafx.h
#include <windows.h>
#include <windowsx.h>
#include <iostream>
#include <iomanip>
#include <string>
#include <vector>
#include <map>
#include <complex>
#include <fstream>
#include <sstream>
using namespace std ;
#include <strsafe.h>
#include <GdiPlus.h>
using namespace Gdiplus ;
#include <CommCtrl.h>
#include <cassert>
class __Init_win32_app
{
private:
ULONG_PTR m_gdiToken ;
public:
__Init_win32_app() ;
~__Init_win32_app() ;
private:
BOOL InitCommonControls() ;
} ;
//stdafx.cpp
#include "stdafx.h"
#pragma comment( lib, "gdiplus.lib" )
#pragma comment( lib, "comctl32.lib" )
#pragma comment(linker,"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
__Init_win32_app::__Init_win32_app()
{
GdiplusStartupInput gdiplusStartupInput;
GdiplusStartup(&m_gdiToken, &gdiplusStartupInput, NULL);
InitCommonControls() ;
}
__Init_win32_app::~__Init_win32_app()
{
GdiplusShutdown(m_gdiToken);
}
BOOL __Init_win32_app::InitCommonControls()
{
INITCOMMONCONTROLSEX iccex ;
iccex.dwSize = sizeof( iccex ) ;
iccex.dwICC = 0
| ICC_LISTVIEW_CLASSES
| ICC_STANDARD_CLASSES
;
return ::InitCommonControlsEx( &iccex ) ;
}
__Init_win32_app win32_app ;
Could you help me with it?
|
|
|
|
|
Umm, does this even link? AFAIK the PCH file is simply the object file created from stdafx.cpp, and if that were true you would be binding the implementation of your class __Init_win32_app to every object file in your project, thus causing error 2005 (' ... already defined in ...'). But I may be wrong.
In any case, I see no reason at all to put your class definition in there. Try moving your class declaration to a separate header and the implementation to a separate source file. The rest of your stdafx.h looks ok to me. stdafx.cpp should only contain the include statement.
|
|
|
|
|
Thanks for improving my codes.
It can be compiled, but I would love to keep the code anomaly to minimum, in case something undefined jumps out of nowhere, and we both know it's a time eater,HOHO.
|
|
|
|
|
Cold_Fearing_Bird wrote: Could you help me with it?
For a start take all that extraneous code out of stdafx.cpp; that file should only contain the very first statement (#include "stdafx.h" ). Also remove all the '__Init_win32_app' class definitions from stdafx.h and place them in a local project include file.
The best things in life are not things.
|
|
|
|
|
I doubt this is related to using PCH. More likely, the debugging information simply wasn't up to date. Changing the setting to use or not use a PCH will force a complete rebuild that of course created the neccessary information and that is why your problem was solved after changing that.
Unfortunately VS was never really good at keeping the debug information accurate. You sometmes do have to force a complete rebuild, either by doing a Clean first, or just by choosing Rebuild All.
P.S.: one of the possible reasons for your debug information to mess up is when files change that are not actually part of your solution, e. g. header files from third party libraries. VS obviously does not check these files, and I never managed to find a setting to fix that. Back in the time when we were still using makefiles I'd simply add a dependency, but I have no idea what to do nowadays...
|
|
|
|
|
My header files( stdafx.h, stdafx.cpp, some routine files) are in a different folder than the project folders I usually work on. Does that tend to cause problem?
|
|
|
|
|
No, as long as you don't get a 'file not found' error you're good. You could put any file anywhere as long as you provide the neccessary paths where to look for them. And you'll notice if something is missing as soon as you try to compile (or link).
|
|
|
|
|
When debugging my App, my VC always steps into disassemble file list and never gets back to my cpp file.It's very annoying How to turn off it?
|
|
|
|
|
If you close the disassembly window it should return to the .cpp file. This usually happens when you press F11 or click on Step Into during the debugging session.
The best things in life are not things.
|
|
|
|
|
The disassembly window will be hidden by default. I think you must have enabled the "Show disassembly if source code is not available" option. Turn it off, and the disassembly won't show up.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
You can find the option at Tools -> Option -> Debugging -> General -> Enable Address-level debugging -> Show disassembly if source is not available .
|
|
|
|
|
Thanks, it's been a while since I visited the VS options.
Watched code never compiles.
|
|
|
|
|
I have a dialog box that pops up in my application. But the popup box is
very large. How can I programmatically set the size of that popup box?
Please any response any one can give me will be greatly appreciated.
Sincerely,
Danielle Brina
|
|
|
|
|
There's a few ways:
- Set the size when you call Create() on the dialog.
- Change the size using SetWindowPos()
- Change the size using MoveWindow()
|
|
|
|
|
I need to right-click on the windows taskbar on the button of a particular application and then select one of the actions in the menu (maximize,restore,close/exit).
Have been trying to get a handle to the taskbar as follows:
HWND hDesktop = GetDesktopWindow();
HWND hTray = FindWindowEx( hDesktop, NULL, _T("Shell_TrayWnd"), NULL );
HWND hReBar = FindWindowEx( hTray, NULL, _T("ReBarWindow32") , NULL );
HWND hTask = FindWindowEx( hReBar, NULL, _T("MSTaskSwWClass") , NULL );
HWND hToolbar = FindWindowEx( hTask, NULL, _T("ToolbarWindow32") , NULL );
But I dont know what to do beyond that or if I am actually getting the correct handle.
|
|
|
|
|
To do this you can find the Window that you need to work on.
Then send it the WM_SYSCOMMAND[^] message.
For example to send the restore command -
SendMessage(hWnd, WM_SYSCOMMAND, SC_RESTORE, 0);
Here hWnd is the handle returned by FindWindow .
|
|
|
|
|
What I want to do is to right-click on a Button on the TaskBar corresponding to a particular running application and then select one of the actions from the Menu that shows.
Any suggestions?
|
|
|
|
|
Try this[^] sample app , you may able to right click on the menu items
HTH
|
|
|
|
|
Hello,
I am writing a program using VC++ with MFC,
I added some dialog boxes and I want that once one of the dialog is opened by DoModal()
all the buttons on the parent dialog will be disabled,
How can I do it?
thanks
Avishag
|
|
|
|
|
In the dialog's OnInitDialog[^] function, you can call EnableWindow[^] on each control.
This is assuming you want the greyed look of the controls; a modal dialog with a parent window automatically disables the parent window until the dialog is closed.
modified 13-Sep-18 21:01pm.
|
|
|
|