|
How to print from the Dialog Box?
Hello!
I have come across some problem hope some one could help me out..
I have got a MFC based dialog box on which i have various controls liek edit boxes, static labels and pushbuttons. For one of the push button say whose caption is "PRINT" i have given the functionality of Printing the same dialog box. I need the dialog box to be printed as is when i click the print button. So what the code should contain and my approach is as follows...
void PrintTest:nPrint()
{
CDC dc;
CPrintDialog dlg(FALSE);
//dlg.GetDefaults();
if(dlg.DoModal() == IDOK)
dc.Attach(dlg.GetPrinterDC());
DOCINFO di;
::ZeroMemory(&di, sizeof(DOCINFO));
di.cbSize = sizeof(DOCINFO);
di.lpszDocName = _T ("print this dialog");
dc.StartDoc(&di);
return;
}
Is my approach correct. I have a doubt, how do i get the dialog handle or the device context i mean the dialog's context so that i can pass the same to the printfunction.
Venky
|
|
|
|
|
http://www.codeproject.com/dialog/msgboxdemo.asp?df=100&forumid=1419&exp=0&select=632516#xx632516xx
According to the above, I created a MFC-AppWizard exe project(Dialog-based) and added the files "timedmsgbox.cpp" and "timedmsgbox.h" to it,then changed the afximpl.h path as: #include "C:\\Program Files\\Microsoft Visual Studio\\VC98\\MFC\\SRC\\afximpl.h"
My computer's OS is WindowsXP sp2
Compiling tool is VC6
The compiling result is like the below
How can I solve these problems?
Compiling...
timedmsgbox.cpp
d:\projects\timedmsgboxtest\timedmsgbox.h(44) : error C2146: syntax error : missing ';' before identifier 'm_sectMap'
d:\projects\timedmsgboxtest\timedmsgbox.h(44) : error C2501: 'm_sectMap' : missing storage-class or type specifiers
D:\projects\TimedMsgBoxTest\timedmsgbox.cpp(28) : error C2039: 'm_sectMap' : is not a member of 'CDlgTimedMessageBox'
d:\projects\timedmsgboxtest\timedmsgbox.h(23) : see declaration of 'CDlgTimedMessageBox'
D:\projects\TimedMsgBoxTest\timedmsgbox.cpp(28) : error C2146: syntax error : missing ';' before identifier 'm_sectMap'
D:\projects\TimedMsgBoxTest\timedmsgbox.cpp(28) : error C2501: 'CCriticalSection' : missing storage-class or type specifiers
D:\projects\TimedMsgBoxTest\timedmsgbox.cpp(28) : fatal error C1004: unexpected end of file found
Error executing cl.exe.
TimedMsgBoxTest.exe - 6 error(s), 0 warning(s)
|
|
|
|
|
Add <afxmt.h> to your StdAfx.h header file, then Rebuild All.
|
|
|
|
|
It work well now
Thank you!
|
|
|
|
|
Hi,
I hope you have solved the current problem as replied by Mike.
When u get error as above, "error C2501: 'CCriticalSection' : missing storage-class or type specifiers", immidiately search "CCriticalSection" on MSDN.
There you will get header file u need to include.
Compiler follows set of instructions. If u forget including header files, it will throw error like above. Error numbers reported by VC compilers are described in detail on MSDN.
If u get compiler concepts clear, u will never face problem in solving such errors.
The chosen One 
|
|
|
|
|
Great!
What a good lesson!
I don't know what to do about these errors before.
Thanks a lot for both of you!
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
I'm trying to extract Thumbnail images of files.
I've used IExtractImage and it works great, except that when it gets to internet shortcuts, it hangs for a long time (10-20 seconds) and always fails.
<br />
TCHAR path[MAX_PATH];<br />
DWORD priority = 0;
DWORD flags = IEIFLAG_ASPECT;
HBITMAP handle = NULL;<br />
CSize requestedSize(75,56);<br />
<br />
if (S_OK == imageExt->GetLocation(path, MAX_PATH, &priority, &requestedSize, 32, &flags))<br />
{<br />
hr = imageExt->Extract(&handle);<br />
<br />
if (S_OK == hr)<br />
{<br />
item->thumbnail = new CMyBitmapFromHandle(handle);<br />
}<br />
}<br />
<br />
imageExt->Release();<br />
I've tried various flags like with or without IEIFLAG_OFFLINE but nothing makes it work.
Does anybody spot the problem ?
Thanks
|
|
|
|
|
Originally, I had a 'struct' in a file along with other 'structs'. Then I added a new class to the program and because this particular 'struct' seemed so well suited with this new class, I moved the 'struct' into the same file with the new class.
Now, even though the file in which the new class is located, has the '#ifndef (etc.)' macro/preprocessor statement, the program will not compile and link due to a LNK2005 error.
The new class is being '#included' in several different class files, and the compiler is not complaining about the new class being multiply defined. Why is the 'struct' the problem?
Thanks for any insight.
William
Fortes in fide et opere!
|
|
|
|
|
Visual C++ sometimes fails to compute dependencies correctly, so you could have a stray definition in an object file from before the move. Try a Rebuild All.
Otherwise, I don't think it's possible to give guidance without seeing the header (so long as it isn't too long - trim out any private implementation and check that the error still occurs) and the exact error message.
|
|
|
|
|
Thanks for replying. (Of the others that have been posted, your's make the most sense.)
Here's the code for the struct file:
#idndef STRUCT_H
#define STRUCT_H
struct FirstStruct
{ etc. };
struct SecondStruct
{ etc. };
...
struct ThisStruct
{ etc. };
#endif // STRUCT_HHere's the file containing the new class:
#idndef HDR_H
#define HDR_H
struct ThisStruct
{ etc. };
class NewClass
{ ctor; dtor; etc. };
#endif // HDR_HClearly it's a Visual C++ misdoing, because there's no C++ syntactical error involved, and if I were to put the 'struct' back to where it was originally located, the program compiles and links well. Then if I were to replace it back with the new class again, the linker acts up and produces the error. Next, if I were to comment out the 'struct' (where it exists in the file with the new class) it compiles and links well. It's ONLY when it appears openly (but separately and apart) from the new class, that the LNK2005 error message reappears.
Of the many situations I tried in getting it resolved, more than half of them involved doing a total "Rebuild all", but the problem still persist.
Yes, I've also deleted the ".ncb" file and a few others too, followed by a "Rebuild all". No difference.
William
Fortes in fide et opere!
|
|
|
|
|
Could the compiler be picking up an old version of your header files?
Visual C++ 7.x supports the /showIncludes switch, which will cause the preprocessor to output where it found the include files. In the environment, this is under Project Properties > Configuration Properties > C/C++ > Advanced > Show Includes.
Visual C++ 6.0 doesn't support this, so you'll have to get it to generate preprocessed output and look through it for the struct definition. You must add the /P /C switches manually (/C keeps comment lines, which will be helpful in locating the problem).
I'm still surprised this is causing a linker, rather than a compiler, error - are you sure that the linker isn't complaining about multiple definitions of a variable or of a function?
|
|
|
|
|
Thanks again for replying.
Your sharp insight into the circumstances I have been describing, provided the clue (more like the answer) to what was needed in order to solve the problem.
When you asked if I was sure that the linker wasn't complaining about the multiple definition of a variable or function, I double check and instantly saw what was the problem. I had:
struct ThisStruct
{ etc.} *pThisStruct;As soon as I removed "*pThisStruct", compiled and linked again, the problem went away.
The reason why such a problem did not exist before, was because the file containing all those structures were being accessed by one (and only one) other file, but to the new file where I relocated that structure, that file is being accessed by three other ".cpp" files, and that's where the multiple redefinitions were occurring.
Thanks again for this big help. I appreciate it.
William
Fortes in fide et opere!
|
|
|
|
|
Hey Mike,
Come to think of it, even though I got a clean compile and link by removing the pointer variable to the 'struct', it shouldn't have mattered because the "#ifndef HDR_H" (etc.) preprocessor statements affiliated with this header file, GAURANTEES that the file would only be "#included" just ONCE!!!!
Therefore, no matter how many times I wish to "#include" that header file elsewhere, the compiler should see it just ONCE!!! (Am I right, or wrong???)
Therefore that pointer variable should NOT have caused any problem. Certainly not the kind the linker was reporting.
William
Fortes in fide et opere!
|
|
|
|
|
The problem is that the same header was included in more than one source file (a preprocessed source file, i.e. including the text of all headers, is referred to as a translation unit in C++ compilation terminology).
The compiler can only 'see' the translation unit it's working on at any one time - it can't see the others.
If you have a.cpp and b.cpp, both of which include hdr.h, and hdr.h includes the definition of a variable, both a.obj and b.obj, generated by the compiler, will contain the definition.
When the linker is instructed to link the objects together, it discovers it has multiple definitions of the same symbol, and aborts with the error.
You should never (or very rarely) define a variable in a header file. If you need to refer to a common variable, declare it extern.
(If you really need to: look up __declspec(selectany)).
|
|
|
|
|
While you do make a lot of sense about what you're saying, I always thought variables, functions, classes and structures defined in the same file (be it a header or an implementation file) reside in the same file scope, and for variables and functions defined OUTSIDE a structure or a class, were considered to be global (of sort).
It might sound like I am talking apples and oranges here, but the idea of scope delimited by the preprocessor statements "ifndef HDR (etc.)" guarantees that those symbols (i.e. variables, functions, etc.) would only be processed (or seen by the compiler) just ONCE!!
"extern" simply says, "Take my word for it, this variable (etc.) you see here, has been defined elsewhere." Its purpose is not just to prevent redefinition (which even so, is questionable because symbols appearing in different files are doing so in a different namespace and would not necessarily be duplicates), but also to prevent problems relative to timing (i.e. at what point does a variable (etc.) becomes known to the system since the compiler does not guarantee a specific order of introduction).
I am trying to think back to all those times when I have defined variables (etc.) OUTSIDE a class, believing that they were symbols simply being defined at file scope (a sort of global version in a way) but that I was safe because the system was only going to see them ONCE if I were to surround EVERYTHING in the file with the "#ifndef (etc.)" preprocessor statements!!
William
Fortes in fide et opere!
|
|
|
|
|
WREY wrote:
the idea of scope delimited by the preprocessor statements [...] guarantees that those symbols (i.e. variables, functions, etc.) would only be processed (or seen by the compiler) just ONCE [...]
Which is true - for a single translation unit.
C++ is now the abnormal language in terms of how a program is built. Most new languages (Java, C#, VB.NET) require all the source files and dependencies to be present at the same time and to be compiled in one go - all the source files must be specified on the command line to build a module. The compiler essentially reads all the source files and the metadata from the dependencies, then generates the code in one go.
C++ has the idea of separate compilation, inherited from C. In Design and Evolution of C++, Stroustrup describes how he'd used Simula in the late 1970s, where he'd make a small change to a module, then wait hours for the system to rebuild everything. In this model, you can compile a single source file that's changed, and link it with the rest of the program using the linker.
In classic C compilers, on UNIX systems, the compiler could only work with one source file at a time. It would launch the preprocessor (a separate program, cpp) to process all the #include statements and #ifdef blocks, strip out comments and perform macro substitutions. It then parses the preprocessed text and generates code from it, storing the result in an object file (sourcename.o on UNIX, typically .obj on DOS/Windows).
It's then the linker's job to pull together all the object files, resolving cross-object references. To simplify things, you can specify a library (.lib or .a) file which is simply a container for one or more object files.
Since the compiler only ever sees one source file at a time, it cannot determine that a variable is defined in two source files. That can only be determined by the linker. Similarly, the compiler proper never sees your preprocessor macros - they have all been eliminated by the time it works on the translation unit. Any lines that were #ifdef'd out are simply eliminated, replaced by blank lines. The only directive that the preprocessor emits that gives the compiler any clue where it is in relation to the original files is the #line directive. This is only used by the compiler to report file and line numbers for errors and warnings.
Visual C++'s cl.exe is a bit more advanced - it can take a large number of source files on its command line and process them in a batch. This saves a certain amount of process creation overhead. It also has the pre-compiled headers feature - it can reuse a preparsed version of many header files and dump that into the current compilation context. Nevertheless, it still treats each file in the same way as the classic UNIX compilers, generating an object for each.
If a variable should only be used in a single source module, you should declare it as static. This prevents the situation where, if someone else defines a variable with the same name (and type in C++) in a different source file, the linker will again complain about multiple definitions.
For even more information, I point you to chapter 9 (Source Files and Programs) of The C++ Programming Language, Third Edition by Bjarne Stroustrup.
|
|
|
|
|
The
#ifndef _HELLO_INCLUDED_<br />
#define _HELLO_INCLUDED_<br />
<br />
#endif
is to makesure that your header / declaration would only be included once in any of your cpp / implementations.
So that eventhough you have mistakenly place in say
#include "hello.h"
#include "hello.h"
included twice, the compiler will not give you error.
Bear in mind that your #include "" statement is sort like calling the header file and paste it into your implentation files.
hope this helps
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Anthony_Yio wrote:
Bear in mind that your #include "" statement is sort like calling the header file and paste it into your implentation files.
Actually, that's exactly what the preprocessor does.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I know. Just trying to be helpful here.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
The second paragraph of my message clearly tells you that I'm using the "#ifndef" macro/preprocessor in the header file in which the new class is contained. IOW, that precaution is already in place.
How does yout reply shed light on why the 'struct' is the cause of the LNK2005 error message?
William
Fortes in fide et opere!
|
|
|
|
|
Sorry for that, it is just a quick reply of mine by not really understand your question.
Could you use namespace instead to organize your codes?
So, you could have files with same namespace.
This is even better I think.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Hi, I try to write a static library, but my classes are templates, so all code is written in .h files. I tried to move the bodies of my classes to .cpp files and compile. Though the library compilation was successful, the test program that tried to use my library throw some linker errors, as expected.
Is there any way to get around with that?
Thank you, Themis
|
|
|
|
|
Have you tried to compile your test program with the modified .cpp before you move on to compile it with static library?
It could be something missing in your header files.
just a suggestion.
Also, by looking at the linker error, you could tell which function prototype is missing.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
If all of your classes are templates, then there's not much you can do, I'm afraid. You can try to refactor the parts of the classes that aren't dependent on the template type into a base class, but the template class will still need to be in the header.
- Mike
|
|
|
|
|
If you don't have any instances of the template class' then there is no issue.
If you have something like :
Template.h :
template<class TT> class TCkPool
{
...
};
and want specific instances of TCkPool exported e.g. a TCkPool<long>, TCkPool<double>, then do :
TemplateExp.h :
#include "Template.h"
typedef TCkPool<long> CkLongPool;
typedef TCkPool<double> CkDoublePool;
TemplateExp.cpp :
template class CMKUTL_API TCkPool<long>;
template class CMKUTL_API TCkPool<double>;
The code in TemplateExp.cpp causes the compiler to create full instances of TCkPool<long> and TCkPool<double>.
If you are creating a dll then :
#define CMKUTL_API __declspec(dllexport)
else for a static lib :
#define CMKUTL_API
...cmk
Save the whales - collect the whole set
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
