|
Yes and No.
I assume you want to import the source files not an external library, which you would just add though your projects settings (make file) and then include the header files in your code.
1) If you just want to add the code/source files to your project then just add them to your work space and include the headers to the code files that access them.
2) If you realy want (or need) to include the code/source files via #include then you do not need to include the header files before those code/source files, since the headers should have been included in the source files them selfs. The 2 problems with including code/source files with #include, (1) you can only include them in only one source file and then use the headers in all other files which may need to access them, (2) you may get multiple definitions because header files in the included files may not have been coded to prevent it. (alright there could be more that 2 problems)
3) Think about it. Basicaly what the preprocessor does is creates 1 big file and then compiles it. This is simplistic, but what it means is that the preprocessor combines your file and the included files in to 1 file before it passes it to the compiler. Therefore, if you include code/source files in each of the files that use them then it is the same as cutting and pasting the contains of those files in to each of those files.
Trust in the code Luke. Yea right!
|
|
|
|
|
Thank you, I will think about it 
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
|
|
|
|
|
Hello!
I have a problem.
I figured out how to use a database on MDI and SDI applications but how can I use one on a Dialog based application?
I want to get some entries of a database and show them to the user on the dialog ( but I dont want to use a SDI or MDI based application... just a dilog based application )... I tried to add a RecordSet and a Recordview on my own and choose a database for it but it gave me some errors...
I already looked the MSDN but I didnt find anything about it ...
Can someone help me?
Please  ...
I thank you for your answers...
|
|
|
|
|
The simplest way is to use DBGrid and then make its dataSource property point to the database.
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
|
MSDN introduces how to customize print dialog,but how to customize print setup dialog?
|
|
|
|
|
In my program:
CString str;
CRect rect;
pDC->DrawText(str,&rect,DT_TOP|DT_WORDBREAK);
If the string is too long,It can be displayed in many lines.
I want to change the system row spacing.How can I do?
|
|
|
|
|
You'll have to change the font. Look up the LOGFONT structure in the MSDN.
Software Zen: delete this;
|
|
|
|
|
 I am trying to include some graphical reptesentations in my MFC(SDI) application. I have successfully drawn bar graphs by using progress bars. But haven't been able to draw pie charts. I have found some controls on the following link but have never used controls other than drag and drop(built-in VC++ ). Plz help me how to use these controls in my program.
http://www.codeguru.com/controls/pie_chart_ctrl.shtml
If there is some other way of doing so plz suggest as I want to adopt the easiest way or ant other type of graphs which are easy to develop.
Reply me soon
|
|
|
|
|
you can use mschart control. it includes a pie chart as well.
You can find it in the gallery. In order to add it simply choose Project->Add To Project->Components and controls->Registered activeX controls and choose Microsoft Char control.
|
|
|
|
|
Usually it'd take me a few seconds to fix an "undeclared identifier" error from the compiler. A bit longer if I'm dealing with namespace issues. This time, however, I've been sweating it for a FEW HOURS and I'm nowhere near finding out what the compiler is talking about.
Here's what happening. I have this dialog class that I designed and created in the Resource editor, which includes naming all the dialog windows, boxes, buttons (etc.), and DEFINITELY, giving the dialog itself a name.
It's the dialog name that the compiler is flagging as the "undeclared identifier" problem.
Because it's a dialog application and I'm dealing with DoDataExchange(), the system is what fills in those information for me, and as far as I can tell, they're ALL there, and they're ALL spelt correctly.
It's the "enum { IDD = IDD_MAIN_DIALOG };" that appears in the class definition is where the compiler is pointing the error as coming from.
There are no missing ";", "{", "(", ")" or misspelt variables preceding this location either that might be causing the compiler to misdiagnose, and since there is only ONE "#include" statement that should be present, no problem in that department either. IT IS THERE, WHERE IT IS SUPPOSED TO BE!!!
In desperation, I even undid some of the changes I made to see if backtracking would help, but not even that brought any comfort.
Can anybody guessed why the compiler is telling me that something I KNOW I HAVE DEFINED, is undeclared?
Thanks for any help. I appreciate it!!!
William
Fortes in fide et opere!
|
|
|
|
|
Did you do this ?
<br />
#include <resource.h><br />
See if that works. If you included the resource.h file in stdafx.h, then clean and rebuild all.
-
Vivek
|
|
|
|
|
#include "resource.h" is present in the header file in which the application class that is derived from CWinApp is defined.
Anyway, I did try putting #include "resource.h" in the header file for which the compiler is complaining about, and it returned even more errors after I did that!! Removed it quickly!!
William
Fortes in fide et opere!
|
|
|
|
|
Is the IDD_MAIN_DIALOG constant #defined in resource.h ?
Is this the only error ?
If your dialog class is in MyDlg.cpp, what is the order of include files ?
It should be
- stdafx.h
- resource.h
- other include files..
It is ok if resource.h is included multiple times, the #pragma once will ensure that exactly one copy is used during compilation.
-
Vivek
|
|
|
|
|
Yes, I have the dialog name constant defined in the "resource.h" file.
I have the #pragma once preprocessor statement present, but when I had #included "resource.h" a second time in dialog class header file, the compiler complained even more. (If you remember, that's what I did the last time and had to remove it.)
I have "#include <<afxwin.h>" in the stdafx.h file, so it's not necessary to repeat "stdafx.h" before the "resource.h" file. (I had to put a double angle bracket in front of "afxwin.h" so that angle brackets can be seen, otherwise the entire word wouldn't show for this message. However, in the program, only a single pair of angle brackets were used.)
William
Fortes in fide et opere!
|
|
|
|
|
Also, did you use the class wizard to create the dialog class, because I had the exact same problem once? Since I became so "proficient" in MFC I decided to write my own class from scratch and you can't even imagine the disaster that I unleashed to the compiler window. What I am trying to say is, recreate the class for that particular dialog and add functions or code little by little. I really hope that there is a better solution because I am dying to find out.
|
|
|
|
|
Your suggestion for a solution may work, and will probably be my last resort for things to get back on the level. However, the reason why I'm not too hot to try it out right away, is because there have been quite a bit of work that I've already invested in this program, and if I have to end up doing something like that all the time, it is foreseeable where I might have to do the same thing over and over again in a few days time, and then repeat it again in a week's time. IOW, it just doesn't sound like something I might want to consider a TRUE SOLUTION, simply to get over the hump.
What I have done, is backtracked on some of the changes I've made, to the point where I was able to compare both ClassWizard files of what things were like back then with what they are, currently, and both files checked out similar. Still, the "undeclared identifier" error remain for the current file (even though I've checked probably a million times already, that the dialog name does exist, declared, defined and spelt correctly.
I don't know what else I may be missing!!
William
Fortes in fide et opere!
|
|
|
|
|
No time for guessing, but I will fix it for you if you send me the project (mail@BartoszBien.com). Discretion assured. 
Regards,
BB
|
|
|
|
|
You are very kind, Bartosz, and it will probably be my second away from the last option. But it's not like me to off-load my problem on someone else, and look upon that as a solution.
Sometimes just mentioning a word "en passant" will turn a light bulb on in my head, and something I may not have thought of, or considered before, suddenly becomes inspirational! Revelation! That's how I believe I'll get this thing solved.
ITM, any idea you may have, is certainly very welcome to hear, and when I have achieved a real solution, be assured it will be revealed.
Thanks anyhow. I appreciate the gesture!!
William
Fortes in fide et opere!
|
|
|
|
|
I see your point  , however it would be easier for me to check the code myself than to guess blindly what to ask you about. Anyway, is your workspace single-project? I.e., is the resource.h that defines IDD_YOUR_DIALOG the only resource.h file in the workspace? Is it actually included? Try adding #error preprocessor command or something alike to see if it is. If it is not - it should not be hard to check why.
Regards,
BB
|
|
|
|
|
Yes, the project is the only one occupying the workspace, and yes, I only have one "resource.h" included in that workspace (that was one of the things I checked out when I began seeing how stubborn and difficult it was to associate the error with the program code).
As mentioned in an earlier reply, I have not seen anything awry (or suspicious) with the ClassWizard file either.
Thanks. I appreciate the input.
William
Fortes in fide et opere!
|
|
|
|
|
Thanks. I appreciate the input.
So - have you checked if resource.h is actually included?
Try some local usage:
UINT myID = IDD_MY_DIALOG;
Does it still report undeclared identifier?
Regards,
BB
|
|
|
|
|
Hello Bartosz, thanks for your reply. It started a change in events!!
In answer to your question whether I had checked if "resource.h" had been physically included in the program, the answer is, "yes". AAMOF, I believe that was one of my earlier replies to "Vivek Rajan". It was a valid question and it deserved a straight answer. Unfortunately, it's inclusion didn't prevent the error from occurring. (It was included from the birth of the program and remained there ever since. It was never removed.)
With regards to the solution, I tried your last suggestion about inserting a new declaration of the same variable to see if that would help; it didn't. The compiler produced about nine new error messages as a result of having a local variable using the same name. (Of course, I first commented out the line where the original variable was located, so as not to have duplicates declarations.)
Then I started a couple more experiments: I thought to myself, how about using a totally different name altogether (just rename every place where the original dialog name occurred with the new name, including inside the Resource editor, and the "resource.h" file)!
This is where the juice began flowing, because if I were to do that, it means I would be removing all references to the old name! OK! Then let see where all references to the old name appear. That was when I commented out the ("enum") line that AppWizard had inserted for me at the creation of the program, compiled it, and naturally it produced its own new set of complaints about what I had just done.
Great! I uncommented the line and compiled it again to see if I still had stability (viz. getting back the same old error about "undeclared identifier"). To my GREATEST ASTONISHMENT, the program compiled and linked WITHOUT ANY ERROR!!! (I stared at the screen for about a good 10 seconds not knowing if what I was seeing was true. I recompiled the program again, and again it compiled and linked without any error!!) Go figure!
Shortly afterwards, subconsciously I found myself singing, "At last, my love has come along. My lonely days are over, and life is like a song!!!"
Like Shakespeare said, "All's well that ends well!!!"
I think I'll continue singing that little song a bit longer!
Thanks for all your input! They proved to be meaningful.
William
Fortes in fide et opere!
|
|
|
|
|
Congratulations!
Well, I haven't done much, but thanks anyway.
Do you know - some say: "All is well that ends."
Regards,
BB
|
|
|
|
|
Not necessarily true about "All's well than ends," because for those things that are "good," you DON'T WANT them to end, and when they do, that's NEITHER good NOR well.
BTW, my birthdate is also in October (just a few days earlier than yours). More fascinating however, are some of the same things you described in your online profile that I also share interest in, such as Artificial Intelligence (for years), and lately, Neural Networks.
William
Fortes in fide et opere!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
