|
Have you included the CreateDlg.h in you UpdateDlg.cpp file..??
if not then include it and try to bulid the application
CreateDlg.h file having the class definition of CCreateDlg class
Knock out "T" from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
// UpdateDlg.cpp : implementation file
//
#include "StatusDlg.h"
#include "stdafx.h"
#include "DesktopSearch.h"
#include "CreateDlg.h"
#include "UpdateDlg.h"
#include "FoldersDialog.h"
I have added CreateDlg.h but still i am getting the same error
|
|
|
|
|
you didn't read the errors properly :
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54)
you have to #include "CreateDlg.h" in the UpdateDlg.h !
one last thing :
move the "stdafx.h" include at the top of all other includes to avoid compilation problems due to the use of precompiled header.
-- modified at 8:12 Monday 10th April, 2006
|
|
|
|
|
UpdateDlg.h
#include "StatusDlg.h" // Added by ClassView
#include "CreateDlg.h" // Added by ClassView
#include CreateDlg.h is add in UpdateDlg.h also but still i am getting error
-------------------Configuration: DesktopSearch - Win32 Debug--------------------
Compiling...
UpdateDlg.cpp
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2146: syntax error : missing ';' before identifier 'm_dCreateDlg'
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2501: 'CCreateDlg' : missing storage-class or type specifiers
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2501: 'm_dCreateDlg' : missing storage-class or type specifiers
Error executing cl.exe.
DesktopSearch.exe - 3 error(s), 0 warning(s)
|
|
|
|
|
Hi ,
just wondering :
Are you sure that your class's name is CCreateDlg and not CreateDlg(when creating a class with 'C' as a first letter - the class wizard , from some reason does not add the prefix 'C' to the claas name... ).
Regards,
Eli
|
|
|
|
|
you're wrong eli.
the class wizard removes the leading C to the file names containing the definition and the implementation of the class beeing created, not directly on the class name.
moreover, look at the errors returned by the compiler :
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2501: 'CCreateDlg' : missing storage-class or type specifiers
yes, the class is effectively CCreateDlg
|
|
|
|
|
Hi v2.0.
You are right
I didn't see that he included the CCreateDlg header file in the Updatedlg implementation file and NOT in the UpdateDlg header file.
About the class wizard - for some reason , in my projects , the class wizard removes the leading C from the class name as well.
With best regards,
Eli
|
|
|
|
|
// UpdateDlg.cpp : implementation file
//
#include "stdafx.h"
#include "DesktopSearch.h"
#include "StatusDlg.h"
#include "CreateDlg.h"
#include "UpdateDlg.h"
#include "FoldersDialog.h"
----------------------------------
//UpdateDlg.h file
#if !defined(AFX_UPDATEDLG_H__440FE7B3_AA09_4A4C_8F1B_6E86EAE82E27__INCLUDED_)
#define AFX_UPDATEDLG_H__440FE7B3_AA09_4A4C_8F1B_6E86EAE82E27__INCLUDED_
#include "StatusDlg.h" // Added by ClassView
#include "CreateDlg.h" // Added by ClassView
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
// UpdateDlg.h : header file
//
----------------------------------------------------
UpdateDlg.h
private:
CCreateDlg m_dCreateDlg;//error
CStatusDlg m_dStatusDlg;
----------------------------------------------
--------------------Configuration: DesktopSearch - Win32 Debug--------------------
Compiling...
UpdateDlg.cpp
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2146: syntax error : missing ';' before identifier 'm_dCreateDlg'
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2501: 'CCreateDlg' : missing storage-class or type specifiers
d:\parichay\desktopsearch\desktopsearch\updatedlg.h(54) : error C2501: 'm_dCreateDlg' : missing storage-class or type specifiers
Error executing cl.exe.
DesktopSearch.exe - 3 error(s), 0 warning(s)
|
|
|
|
|
Do you realy have a sub directory called desktopsearch inside the directory with the same name?
|
|
|
|
|
I think the error is because you are cross-including files; I mean including fileA.h in fileB.h and fileB.h in fileA.h etc. You could just declare the class like:
class CCreateDlg;
Then declare a pointer:
CCreateDlg* m_pDlg;
etc.
this is this.
|
|
|
|
|
Thank u very much its working.
|
|
|
|
|
Hi,
i have new button on sigle click i want a dialog window to open i have declared variables as follows..
can anyone help to solve this problem..??
UpdateDlg.h
#include "StatusDlg.h" // Added by ClassView
#include "CreateDlg.h" // Added by ClassView
private:
CStatusDlg m_dStatusDlg;
class CCreateDlg;
//Then declare a pointer:
CCreateDlg *m_dCreateDlg;
---------------------
// UpdateDlg.cpp : implementation file
//
#include "stdafx.h"
#include "DesktopSearch.h"
#include "StatusDlg.h"
#include "CreateDlg.h"
#include "UpdateDlg.h"
#include "FoldersDialog.h"
void CUpdateDlg::OnNew()
{
// TODO: Add your control notification handler code here
m_dCreateDlg.DoModal();
}
---------------------------------------------------------------
--------------------Configuration: DesktopSearch - Win32 Debug--------------------
Compiling...
UpdateDlg.cpp
D:\Parichay\DesktopSearch\DesktopSearch\UpdateDlg.cpp(182) : error C2228: left of '.DoModal' must have class/struct/union type
Error executing cl.exe.
DesktopSearch.exe - 1 error(s), 0 warning(s)
|
|
|
|
|
I don't think you are very familiar with pointers and their uses. Using the pointer to declare the variable would mean that you have to give it memory by using the new operator. Then create the dialog using Create(...) then show the dialog using ShowWindow(...).
This could be the code:
class CCreateDlg;<br />
CCreateDlg *m_dCreateDlg;
Now on button-click:
m_dCreateDlg = new CCreateDlg();<br />
m_dCreateDlg->Create(IDD_WHATEVER);
m_dCreateDlg->ShowWindow(SW_SHOW);
This would create a modeless dialog.
Note that this would give memory leaks if you do not dispose if off correctly. And if you want to re-use the pointer to create the dialog again, there could be problems.
Another way would be:
m_dCreateDlg = new CCreateDlg;<br />
m_dCreateDlg->DoModal();
this is this.
|
|
|
|
|
Hi all,
In my MDI application, when I call printpreview CView::OnFilePrintPreview(..), I am getting an assertion in CDialogBar::Create(..) in Static Libary build. It works fine in Shared Library version.
Project Settings:
********************
C/C++ Tab:
Category: Code generation
Use Runtime library: Multi-threaded
I've tried both Debug & Release with the above settings.
What's wrong with this?
Regards,
Sarvan AL
|
|
|
|
|
hi,how to use a third party dll in a specific project, and
what r the things i need to know while using third party Dll in my project?
krishna
|
|
|
|
|
You can import those DLLs in your application
Knock out "T" from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
Checking to see if anyone as any good comment to this scenario...
Using VS2005 to convert a server app to 64 bit. Running it on a Xeon ~3 GHz with 2 GB RAM etc. Since it is Xeon, we are talking EM64T and not AMD which might be the cause of this strange result:
In debug compilation, x64 wins with 30%
In release build, x86 wins with about 10% which seems pretty odd but there's nothing I can do about it.
I've tried to check just about any project configuration option I can possibly think of, but the same result. Obviously something is different between release and debug, but is it VS2005 or am I missing something? The same project config in all cases too. Could it be that VS2005 optimizes it's release code for AMD64 and that EM64T is different is the cause of the difference?
TIA
|
|
|
|
|
There is a C/C++ command line option: /favor:AMD64, but it is not enabled by default, nor would it explain your results.
http://msdn2.microsoft.com/en-US/library/ms173505(VS.80).aspx[^]
Burtraskkutaren wrote: In debug compilation, x64 wins with 30%
In release build, x86 wins with about 10%
Could it be that VS2005 optimizes it's release code for AMD64 and that EM64T is different is the cause of the difference?
There isn't enough information about your code/compiler settings to say.
My own informal tests with my code shows that my x86 and x64 builds perform about the same (i.e. release x86 ~= x64, debug x86 ~= x64).
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Yep, I know, it really shouldn’t be that much of a difference but still it is. And the +30% in debug performance is completely accurate, no doubt about it. I’m going to check out the suggestions above as well as testing of different amount of simultaneous connected clients today. A little more info about the test environment:
The application is a kind of a webbserver, working with more or less large XML files. This actual version is single threaded, using MFC sockets. That means that CPU load is ~25%, Dual Xeon with HTT.
Testing is done through ACT (Microsoft Application Center Test) where a simulated surf action is recorded. Of course, same test in both cases. The biggest amount of testing has been done with 50 clients, where the results are those I’ve already mentioned. During testing in debug mode, CPU load is pretty even throughout the test but when running in release it seems to differ a bit more with periods of much less load. Preliminary testing yesterday, which I’m going to follow up now this morning, seemed to show that more normal performance was obtained if the number of clients in ACT was reduced to 1.
I’ll try to return later today with those results, the compiler settings isn’t so much to argue about since I’ve even tried to have the same settings in debug/release without any real measurable difference.
Release 64: /O2 /Ob1 /I "." /I "..\\" /I "..\..\private\include" /I "..\..\public\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /GF /FD /EHsc /MT /Gy /Yu"stdafx.h" /Fp".\R/ErrorService.pch" /Fo".\R/" /Fd".\R/" /W3 /nologo /c /errorReport:prompt
release 32: /O2 /Ob1 /I "." /I "..\\" /I "..\..\private\include" /I "..\..\public\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /GF /FD /EHsc /MT /Gy /Yu"stdafx.h" /Fp".\R/ErrorService.pch" /Fo".\R/" /Fd".\R/" /W3 /nologo /c /errorReport:prompt
Debug 64: /Od /I "." /I "..\\" /I "..\..\private\include" /I "..\..\public\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /FD /EHsc /RTC1 /MTd /Yu"stdafx.h" /Fp".\D/ErrorService.pch" /Fo"x64\Debug\\" /Fd".\D/" /W3 /nologo /c /Wp64 /ZI /errorReport:prompt
Debug 32: /Od /I "." /I "..\\" /I "..\..\private\include" /I "..\..\public\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /FD /EHsc /RTC1 /MTd /Yu"stdafx.h" /Fp".\D/ErrorService.pch" /Fo".\D/" /Fd".\D/" /W3 /nologo /c /Wp64 /ZI /errorReport:prompt
|
|
|
|
|
All-in-all i would find it hard to measure a web-server type app, where caching can play such a big part of the performance ... and there are so many places where data gets cached.
You say the version being tested is single-threaded, so i take it the network code is using select or wait on mutexes as opposed to IOCP. Maybe there is some difference in the x64 winsock library, or the x64 driver for your network card.
I would first try a console based numerical comp app and compare those runs first to try and narrow down what subsystem (e.g. networking, GUI, OpenGL, ...) is causing the difference.
I would (have) bite the buttlet and go unicode (_UNICODE instead of _MBCS) as (almost) all internal OS data is transmitted using unicode.
You may also want to look at:
http://msdn2.microsoft.com/en-us/library/9yb4317s(VS.80).aspx[^]
In particular you have /D WIN32 for your x64 builds, the bottom of the above MSDN page states "Values of WIN32 are replaced by WIN64" ... might make a difference in some of the win headers (doubt it though).
I also ended up blowing away the sln the upgrade wizard created, wasn't happy with it.
In general the Property Manager hasn't been very good in setting up 32/64bit builds, i ended up having to edit the sln and vsproj files directly to get what i needed.
For reference here are (short version) settings for one of my apps:
Release 64:
/Ox /Ob1 /Oi /Ot /GT /GL /D "WIN64" /D "NDEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /GF /FD /MD /GS- /fp:fast /GR- /W4 /nologo /c /Wp64 /Zi /TP /errorReport:prompt /favor:AMD64
Release 32:
/Ox /Ob1 /Oi /Ot /GT /GL /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /GF /FD /MD /GS- /arch:SSE2 /fp:fast /GR- /W4 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Debug 64:
/Od /D "WIN64" /D "_DEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /GF /FD /MDd /GS- /fp:fast /GR- /W4 /nologo /c /Wp64 /Zi /TP /errorReport:prompt /favor:AMD64
Debug 32:
/Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /GF /FD /MDd /GS- /fp:fast /GR- /W4 /nologo /c /Wp64 /Zi /TP /errorReport:prompt
Good-luck
...cmk
Save the whales - collect the whole set
|
|
|
|
|
A few answers so far...
/favor:EM64T only performed worse.
Network code, well haven't dug into it deeply enough but it's all into MFC, and how they have solved it I don't know.
Unicode, well maybe later since it generates a couple of hundred compile errors right now 
/D Win32, seems like it gives slightly better performance than /Win64...
I did test yesterday with some special variant of the code, which generated more reasonable results (+10-20% for 64bit in release) but I'll have to keep on digging deeper to find the possible solution to it. One theory of mine is that there might be some conversions / larger datatypes that messes things up although it would be most logical if it would generate same performance debug/release...
It might be possible that it is the Winsock library, I doubt that it is the NIC because NIC drivers have to be 64-bit in a 64-bit OS to work. All tests are done in Win2003Server x64...
Keeping on searching for an answer 
|
|
|
|
|
Hi there,
I would like to create a message-only window to handle messages from external applications. But how do I go about doing that? I couldn't possibly run a message loop in a DLL after I have created a window, can I?
// after CreateWindow is successful
while ((bRet = GetMessage(&msg, NULL, NULL, NULL)) != 0)
{
if (bRet == -1)
{
// some code ...
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
|
|
|
|
|
if i am correct are you trying to hook the other applications..???
and it is not possible to write the message loop into the win32 DLL as its drawback of dll
Knock out "T" from CAN'T
You 'CAN' if you think you 'CAN'
|
|
|
|
|
Hi all,
We have a class CBitmapButton which is derived from cButton. We need to enable the tool tip for this class. We have written the code for the same.
We have followed all the steps required to enable a tool tip for this button. However we are facing a problem while displaying the tool tip. The tool tip is seen at first when the mouse is moved to this button. If we hold the mouse on that button, after some time, the tool tip vanishes and then the tool tip is never seen even if the mouse is moved to the next button and brought back to this button .
Please suggest some solution to the above problem.
Any kind of help would be appreciated.
Thanks
amit
|
|
|
|
|
can you give he short code snippet what you are doing so that someone can find out where you are gong wrong
Cheers
"Peace of mind through Technology"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
