|
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.
|
|
|
|
|
Just a query: Why do you want to disable the controls on the parent dialog i.e. only for the look and feel?. Since the dialog being popped up is a result of the DoModal thing, the hit on the parent dialog will not work unless you dismiss the popped dialog.
On the other hand as suggested with the parent dialog pointer you can disable the control on it in the InitDialog of the dialog being popped up.
You talk about Being HUMAN. I have it in my name
AnsHUMAN
|
|
|
|
|
thanks for the replay,
I have a dialog that has a menu and clicking on the menu items causes to open other dialogs
by DoModal();
The problem is that, while one dialog is opened the user can click other menu items and open more dialogs and its causes me a mess.
How can I declare that the main dialog will be a parents of the other dialogs?
thanks again
|
|
|
|
|
aangerma wrote: The problem is that, while one dialog is opened the user can click other menu items and open more dialogs and its causes me a mess.
Are you certain you are calling DoModal ?
If the dialog is modal (DoModal) the parent window should not be active and the user should not be able to click on other menus/buttons.
If that is happening, you have other issues to fix.
Watched code never compiles.
|
|
|
|
|
Maximilien wrote: indow should not be active and the user should not be able to click on other menus/buttons.
Can i correct it as
If the dialog is modal (DoModal) the parent window will not be active and the user will not be able to click on other menus/buttons.
|
|
|
|
|
Yes, you can; but if the user experiment another behavior, there is a bigger issue.
Watched code never compiles.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
