|
Which version of the library are you using? The Exception class is part of the PDFlib class, not part of the PDF class as the error message correctly states.
What is really odd with your error message is that the code is to instantiate a PDFlib::Exception object which is valid, but the error message says that Exception is not part of PDF. Where is PDF declared?
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
Object Exception is declared in pdflib.hpp , which is included in top of file that contain listing code : #include "pdflib.hpp" , still , Exception object is not recognized in catch statement ... 
|
|
|
|
|
I noticed something : Exception object have precompiled statement :
#ifdef PDF_THROWS_CPP_EXCEPTIONS class Exception { public:
Exception(string msg, void *opaque); string get_message();
const void *get_opaque();
...
...
...
I put same thing on try/catch statement and I not have compile errors anymore , but , when program front that dummy code , programs stop without any warning , which prove that catch statement don't catch really error ...
|
|
|
|
|
Hello,
I am having a problem with iostream in the header file FlexLexer.h and the generated output of the gnuwin32 flex -+ code.
I am using the flex tool of gnuwin32
flex
and want to use the -+ switch to create "c++" code.
If I compile the flex generated code and the FlexLexer.h header I get the error
fatal error C1083: Cannot open include file: 'iostream.h': No such file or directory
I replaced the #include <iostream.h> in the FlexLexer.h with
#include <iostream>
using namespace std;
but now I get the error:
error C2872: 'istream' : ambiguous symbol
This error occures because the generated code contains a forward
class istream;
Is there a way to get rid of it and to replace it with
#include <iostream>
using namespace std;
Can anyone help me with this problem?
Thanks a lot,
Andreas.
Andreas.
|
|
|
|
|
Yes since istream is in the std namespace, its forward declaration must also be in std namespace. Change the forward declaration to:
namespace
{
class istream;
};
-Saurabh
|
|
|
|
|
That doesn't help, than I get the following error:
FlexLexer.h(66) : error C2872: 'istream' : ambiguous symbol
1> could be 'C:\Program Files\Microsoft Visual Studio 8\VC\include\iosfwd(700) : std::basic_istream<_Elem,_Traits> std::istream'
1> with
1> [
1> _Elem=char,
1> _Traits=std::char_traits<char>
1> ]
1> or '.\abc.cpp(27) : `anonymous-namespace'::istream'
Andreas.
|
|
|
|
|
Hello,
everybody who is interested in, I found a solution (workaround)  for the iostream problem:
First replace FlexLexer.h the line
#include <iostream.h>
with
#include <iostream>
using namespace std;
than modify the skeleton file
flex.skl that you can find in the unix version flex and replace the line:
class istream;
with
#include <iostream>
using namespace std;
than use flex with the skeleton file argument: -Sflex.skl
Cheers,
Andreas.
Andreas.
|
|
|
|
|
Thanks for your post, it's saved me a lot of headache
maybe we can finetune it a little: the first part is redundant since you already do
#include <iostream>
using namespace std;
in the skeleton/generated code
I see two options here:
1. do
#include <iostream>
using namespace std; in the skeleton and just comment #include <iostream.h> out of FlexLexer.h
maybe this is cleaner since FlexLexer.h depends on iostream:
2. replace #include <iostream.h> with
#include <iostream>
using namespace std;
in FlexLexer.h and in the skeleton move FlexLexer inclusion forward so you dont need isstream forward definition anymore:
#include <FlexLexer.h><br />
hope this helps 
|
|
|
|
|
I heard that GUI updation is not preferred in Worker Thread.
Does any one tell me the reason with the help of a msdn article. 
Ajayraj
|
|
|
|
|
Have a look at this article[^] at the section called "Worker threads and the GUI II: Don't touch the GUI".
|
|
|
|
|
It would be not possible
to manage any alarm events or even the mouse click events -
without the updating of a complex drawn picture
(for example, with motions, blinking, transformations, Direct2D interludes...) -
by a worker thread... But it is possible (with a worker thread)
virtual void BeHappy() = 0;
|
|
|
|
|
I want to use the CHtmlEditView in my vc 6.0 project, it is a MFC project.
so i added the header file 'afxhtml.h' and then added the following line.
CHtmlEditView htmleditview_object;
then i compiled the project and its giving the error like
error C2501: 'CHtmlEditView' : missing storage-class or type specifiers.
what should i do?
How do i solve this problem?
sunnyram
|
|
|
|
|
I know this is an obvious (stupid?) question, but are you sure you put your #include in the correct source module?
It's time for a new signature.
|
|
|
|
|
I was wondering that, but decided not to ask...
Steve
|
|
|
|
|
Yes, i have put #include in correct source module and what is the new signature?
can you explain little more?
sunnyram
|
|
|
|
|
sunnyram wrote: what is the new signature?
can you explain little more?
That way you should explain 'sunnyram'.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Maybe you could just create one simple source moudule containing the #include statement and the CHtmlEditView declaration to see if it compiles, and if not, if you get any other messages. Also it may help if you post the source here so we can see exactly what you have coded.
It's time for a new signature.
|
|
|
|
|
sunnyram wrote: so i added the header file 'afxhtml.h'...
To where?
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.)
The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg
(true,
"bdb",
NULL,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST,
szFilter,
NULL);
fdlg.m_ofn.lpstrInitialDir = OutputDoc;
And then:
if (fdlg.DoModal() == IDOK)
{
strcpy(BINFODB, fdlg.m_ofn.lpstrFile);
pApp->AddToRecentFileList(BINFODB);
pApp->UpdateTitleBar(&(pApp->m_pMainWnd->m_hWnd));
}
In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL).
What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine.
Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
|
|
|
|
|
permutations wrote: literally identical (I put the DOS code in a DLL).
This could be part of the problem; if the code is compiled for 16 bit and DOS, the emulation needed for it to work at all would slow it down. Plus depending on the implementation of said emulation, it may be artificially making it run slower to better mimic the original platform.
You may want to consider porting the program to target Windows (32 bit at least).
|
|
|
|
|
It's compiled for 32-bit - sorry I didn't make that clear. The engine code was pulled from the original DOS program, and then recompiled for 32-bit Windows and packaged in a DLL. It's straight C code - should be efficient.
Anyway, this isn't the part that is running slowly. It's the file open dialog, which is strictly on the interface side and has nothing to do with the original DOS code. To adapt the DOS program I separated out the interface and the engine, put the engine in a DLL, and wrote a Windows interface. It's the file open dialog in the Windows interface that is slow as molasses, and it's such a simple call. I don't get it. Just bringing up the file open dialog box takes a really long time.
|
|
|
|
|
One crude technique I use sometimes is simply to break into the application periodically with a debugger and have a look at the call stack. Perhaps you'll get lucky and see the problem. A profiler would obviously be helpful and a lot more informative than my poor-man's profiler. Another classic is to simple scatter timing code throughout your code.
Steve
|
|
|
|
|
Hmmm... That's a good thought. I don't have a lot of experience with profiling and looking for inefficiencies in code. I guess the call stack would tell me if weird things are being called that I didn't realize.
> Another classic is to simple scatter timing code throughout your code.
Could you explain more what you mean by timing code? You mean stick in traces that ... what would I trace - the entry and exit times in different functions?
|
|
|
|
|
I think I may have a clue what's causing this...
I'm developing the program with VS2008 on the Windows 7 machine, but I'm maintaining compatibility with VC++6 on an XP machine because I want to compile the release version there. This is a commercial program for home users, and my customers will mostly be running XP. I don't want to statically compile MFC, and I don't want to make them go get updated DLLs.
On the XP machine, there is no delay in the file open dialog. It's just on the Windows 7 machine. I think this is because the common file dialog has been superceded on Vista and later:
http://msdn.microsoft.com/en-us/library/ms646927(VS.85).aspx[^]
I'll try switching to GetOpenFileName. If that's faster on Windows 7, then maybe I can use precompiler directives to use GetOpenFileName on Vista or later.
|
|
|
|
|
could your problem be related to this[^] ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
