|
Thank you so much for your answers (both of you), I will try that right away and tell you what I've done ... but it came into my mind a question ... if I could store pointers into SetItemData(...), why CListBox does have SetItemData and SetItemDataPtr ... it is not a kind of redundancy ?
|
|
|
|
|
Flaviu2 wrote: but it came into my mind a question ... if I could store pointers into SetItemData(...), why CListBox does have SetItemData and SetItemDataPtr ... it is not a kind of redundancy ?
Doesn't SetItemDataPtr() internally cast and call SetItemData()?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I think that you are right ... thanks !
|
|
|
|
|
Does function well ... Thanks !
|
|
|
|
|
Dear All,
I'm new to C++\ MFC so I hope my questions are easy to answer.
I tried to add a user defined message-handler to an CDialog derived class by adding the following:
1. defining a message
#define WM_UPDATE_UI WM_USER+1
2. declare method
afx_msg LRESULT OnUpdateUI(WPARAM wParam,LPARAM lParam);
3. extend message map
BEGIN_MESSAGE_MAP(CMyDialog,CDialog)
...
ON_MESSAGE(WM_UPDATE_UI,&CMyDialog::OnUpdateUI)
END_MESSAGE_MAP
4. handle message
LRESULT CMyDialog::OnUpdateUI(WPARAM wParam,LPARAM lParam)
{
return 0;
}
Because of the message map entry i recieve the 14 errors:
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(33) : error C2143: syntax error : missing '}' before ';'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(33) : error C2143: syntax error : missing '}' before ';'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(33) : error C2143: syntax error : missing ';' before ','
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(33) : error C2059: syntax error : ','
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2143: syntax error : missing ';' before '{'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2447: '{' : missing function header (old-style formal list?)
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2059: syntax error : '}'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2653: 'TheBaseClass' : is not a class or namespace name
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2065: 'GetThisMessageMap' : undeclared identifier
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2065: '_messageEntries' : undeclared identifier
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2059: syntax error : 'return'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(34) : error C2059: syntax error : '}'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(40) : error C2143: syntax error : missing ';' before '{'
2>e:\projects\dummyactivex\dummyactivex\mydialog.cpp(40) : error C2447: '{' : missing function header (old-style formal list?)
I really don't know the error, please help!
Thanks in Advanced.
|
|
|
|
|
I can't see anything seriously wrong in the posted code. So the error may be also somewhere else (probably in a line before number 33 in mydialog.cpp). A possible error source is forgetting the trailing semicolon after the class declaration:
class CMyDialog : public CDialog
{
};
I have some more notes:
You should always use parentheses with definitions and macros:
#define WM_UPDATE_UI (WM_USER+1)
The afx_msg prefix is not necessary:
LRESULT OnUpdateUI(WPARAM wParam,LPARAM lParam);
In the message map, just pass the function name:
ON_MESSAGE(WM_UPDATE_UI, OnUpdateUI)
|
|
|
|
|
Oh my goodness!
you're right, it is caused by a semicolon before class definition.
So of course now the error message makes sense.
Sorry for wasting time 
|
|
|
|
|
Thank you for your feedback.
Such mistakes happen (even to me after years of programming). When forgetting the semicolon at the end of a header file, the error is thrown at the first semicolon in the next file which might be another header file or the source file. If you remember this and get such a bulk of messages the next time, you will probably know where to look first.
|
|
|
|
|
Looking at some of those messages they do not look like they are connected to the code you posted. Show us the content of lines 1 to 40 of e:\projects\dummyactivex\dummyactivex\mydialog.cpp.
Use the best guess
|
|
|
|
|
It seems that one of the major obstacles in developing a real application is lack of understanding of one of the fundamental language features – in this case C preprocessor. Majority of coding articles posted here ignore such details.
I am sure this can be applied to any C derivative - C++, C# and other languages.
I think I got the basics, but would like to know how compiler applies stuff like “dependencies” , settings – preprocessor “additional includes” and “Options – directories”.
Of course I am using VS/VC 6.0 terminology and it will be different in later VS IDE's
Any educational commentaries are much appreciated. References, links etc would be great.
And after this discussion is done, I'll ask about usage of #pragma – I am currently using it to stop the compiler when there are too many initial error. Crude but works for me.
Appreciate your time.
Cheers Vaclav
|
|
|
|
|
Vaclav_Sal wrote: would like to know how compiler applies stuff like “dependencies” , settings – preprocessor “additional includes” and “Options – directories”.
It doesn't, these are merely convenient ways of indicating how your source code should be compiled, and all are used by Visual Studio to build the command and options used to invoke the compiler. The preprocessor reads the source file, expands #included sources and macros, and passes the resulting source to the actual compiler. You can set options in VS to get the output of the preprocessor saved to a file.
Vaclav_Sal wrote: And after this discussion is done, I'll ask about usage of #pragma
You will find all information on pragmas at http://msdn.microsoft.com/en-us/library/d9x1s805.aspx[^]. And for general information on Visual C++ see http://msdn.microsoft.com/en-us/library/ty9hx077.aspx[^]
Use the best guess
|
|
|
|
|
Thanks Richard,
in VS\VC 6.0 there is an *.opt file which comes from "Options".
(For now I forgot how to get to the compiler command line itself.)
An easy way to change path used during development at once, I am using plain Notepad.
I have not found a way to do it in IDE itself.
Acually this post was promted by me being curious if the sequence of "includes" in Option setting matters. I guess I shall test that after I get my app to work again - my XP crashed!
Thanks for your time.
Vaclav
|
|
|
|
|
I'm afraid it's quite a few years since I used VC 6, and it was quite different in many ways from the Visual Studio versions. However, you should be able to check and see all the various items by using the Project -> Properties link in the solution explorer.
Use the best guess
|
|
|
|
|
Yes, and I think I also remember that the command lines (or at least the parameters for the current settings) for the compiler and the linker were shown in the property window.
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
Yes, I think it was the last item in the property tree for each command, same as the more modern versions.
Use the best guess
|
|
|
|
|
Vaclav_Sal wrote: I think I got the basics, but would like to know how compiler applies stuff like “dependencies” , settings – preprocessor “additional includes” and “Options – directories”.
The phases of translation during program compile are described here[^].
Information about #pragma is compiler specific. The info for Visual Studio can be found here[^].
--
Harvey
|
|
|
|
|
Thanks, very good link. Appreciate that.
|
|
|
|
|
Vaclav_Sal wrote: It seems that one of the major obstacles in developing a real application is lack of understanding of one of the fundamental language features – in this case C preprocessor.
That isn't true.
Vaclav_Sal wrote: I am sure this can be applied to any C derivative - C++, C# and other languages.
It doesn't apply in the same way to C# as it does to C/C++.
Vaclav_Sal wrote: I think I got the basics, but would like to know how compiler applies stuff like “dependencies” , settings – preprocessor “additional includes” and “Options – directories”.
I suspect you are confusing how '#include' resolves stuff versus how similar looking but substantially different idioms work in C#.
Vaclav_Sal wrote: I am currently using it to stop the compiler when there are too many initial error.
Eventually you should stop doing that.
|
|
|
|
|
Not what I really expected, but if I added "MY lack of understanding" you would probably get little more personall with your response.
I am not confusing anything with C# since I don't use it.
And don't tell me not to use #error - it does what I want, so what if it is not "cool".
ANyway, thanks for your response.
|
|
|
|
|
Vaclav_Sal wrote: I am not confusing anything with C# since I don't use it.
You said "...C# and other languages" so I presumed that C# was in fact relevant.
Vaclav_Sal wrote: And don't tell me not to use #error - it does what I want, so what if it is not
"cool".
Your presumption about my reasoning is incorrect. Your stated usage is incorrect because with more experience the way in which you deal with compilation units, regardless of language, will change. And thus your current idiom will be less useful and can in fact interfer with correctly determining problems.
|
|
|
|
|
Vaclav_Sal wrote: lack of understanding of one of the fundamental language features – in this case C preprocessor
There isn't much to understand:
1. don't use #define if you can help it
2. #include simply inserts the text of the listed file at that position. This has some implications as to what you should and shouldn't put in there, but that is really all there is to know.
3. #pragma commands depend on the compiler
Vaclav_Sal wrote: I think I got the basics
If you mean by "real application" a program consisting of two or more files, then yes, you need to understand how includes work. IMHO you haven't got the basics until you understand at least that much. Maybe the typical introductory programs (like "hello world") should use a custom include file just to point out the importance of this technique in C/C++ ...
As for the other settings you mentioned, these are mostly irrelevant for understanding the preprocessor functionality. Also they're specific to VS/VC, not the C/C++ language in general. Each compiler and IDE use these differently, so you should learn about these settings by reading them up in the compiler documentation.
|
|
|
|
|
Stefan,
thanks for reply. I find your objection to using #define peculiar.
For example – the basic MFC wouldn’t fly without it. The first C program I wrote over 30 years ago I used #define MAX 256 to have a single place in the program where the value of MAX can be changed. And how about #define DEBUG?
I think stating that #include just adds the file text is rather simplistic. I was actually looking to discuss experiences / preferences in putting include in various places of application. In VC6.0 you can put “include “ in Project Settings, in Tools Option in an addition to files. I am sure newer IDE's have similar options.
I just went thru couple of sleepless nights trying to find linker error – cannot find file “g:.lib”.
Simple search just did not work this time.
Well I had a #pragma comment referring to a wrong directory. So my experience with VC6.0 #pragma - it works but is not that user friendly.
Cheers Vaclav
|
|
|
|
|
I did say "if you can help it", and the implied advice was that you should avoid #define, if there is a better method. There are better methods for every single example you gave:
1. #define DEBUG
This is used for conditional compilation, to add more code that helps your debugging. Normally such a define should not be right in your code, as it specifies which path to use for compilation and which to ignore. Instead you sheould set that in your compiler options, or directly pass it as a command line argument to your compiler (something like "-D DEBUG")
Maybe what you meant was code enclosed in #ifdef DEBUG ... #endif - but I have no qualms with that.
2.#define MAX 256
Since Ansi C, you should use this syntax instead:
const int MAX=256;
3.#define max(a,b) (a < b ? b : a)
With C++ templates, you should better use this instead:
template <class T>
T max(const T& value1, const T& value3) {
return (value1 < value2) ? value2 : value1;
}
On a sidenote, since you mention MFC, the windows header files contain a min and max macro just like that listed above. And you don't even have to write some clever code to make it crash: just include valarray (a STL class header) in your windows application, instantiate a valarray variable and try to compile that!
You mention how you wrote code 30 years ago, and how MFC uses #define a lot. Please think about the implications: Yes, MFC used #define a lot 30 years ago, just like you did. But that doesn't mean that this is still recommended üpractice today!
Vaclav_Sal wrote: I think stating that #include just adds the file text is rather simplistic.
To the contrary, it is very concise. You are mixing up include options that you can enter in the project and compiler settings with the include statements in your code. These options will only tell the compiler which directories to search or skip when looking for an include file.
|
|
|
|
|
Hello friends
I am using Owner Draw menuItem Icons in MFC application. Now, when I Run it in release build,menus are displaying fine But in Debug Build,MenuItem are large in size that covering full screen.
Any IDeas ?
Regards
Y
|
|
|
|
|
yogeshs wrote: Any IDeas ?
You have a bug in your program. Unless you provide some proper detail information it is impossible to guess; we have no idea what your code is doing.
Use the best guess
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
