_WINDOWS

[Lloyd Etheridge]

Hi guys.

its a long time since I been on this thread but I am trying to add pdf
file writing and not sure if there is any good programs to add however I
found one that I am trying to use
http://www.idealsoftware.com/en/download/vpe_win.html engine.
I did a test on my watcom 1.7 compiler project Win32[NT/Win95/Win32]
Character-mode Executable [.exe] and it does not understand #ifdef
_WINDOWS only if I change it to _WIN32 why is this the case or do I need
to upgrade to a later version.

P.S. not sure if there is a better API that I can add to do it ...only
learning about pdf writing

Thanks in advance
Lloyd.

[Hans-Bernhard Bröker]

On 15.01.2012 06:30, Lloyd Etheridge wrote:

> I did a test on my watcom 1.7 compiler

Why use such an out-of-date version of an open-source tool?

> and it does not understand #ifdef
> _WINDOWS only if I change it to _WIN32

It might help if you told us how you expected it to "understand" that.
AFAIK, _WINDOWS (all capitals) has never been a pre-defined symbol on
Windows compilers. _Windows was, but that's a different thing.

[Lloyd Etheridge]

Hans.
Thanks for the quick reply.
I havent upgraded as I had not needed to and sometimes upgrading
software can be a nightmare when you really dont want things to go
wrong... I do take your point and will look at upgrading it soon.

I tried changing it to what you suggested and still no response it does
not accept _WINDOWS nor _Windows only the _WIN32.

I must admit I am not that familiar with the compiler as I have been
more atune to the software result than the method of compiling ..call it
bad programming but when trying to do a major programming job on your
own doesnt give you time of day to learn it all. I am amazed at how
others seem to learn so much and then have to write the program to do
what this world demands...but thats another story I think.

The script I am referring to is an out of the box copy from VPEDEMO.CPP
from
http://www.idealsoftware.com/en/pdf-library/sample-code/overview.html
and assumed that their sample code was correct but returned the error
that I had mentioned.

I will refer their error to them but wasnt sure it was something that i
had done wrong or it was within the compiler.

Thanks for your reply I will have to seek advice from the author as to
what is wrong.
I have been searching for days a good pdf dll but wihtout paying a high
price for one there isnt too much around that is simple and easy to add
via the compiler or its just that I am out of touch with it all, the old
brain aint what it used to be.

cheers
Lloyd

[Kevin G. Rhoads]

>I have been searching for days a good pdf dll but wihtout paying a high
>price for one there isnt too much around that is simple and easy

It depends upon what you want to do. For creating PDFs, you can print
to any PostScript printer driver saving to a file and GhostScript will
convert that to PDF quite nicely. Not as clean as a full programatic
solution, but totally free and fairly easy. Now if you want to read,
display or OCR PDFs, then that is another set of issues.

Next, if this tool worked well for you, why do you look to move away
from it? Are Win16 targets too limiting?

What are you want to get from OW in this?

[Paul S. Person]

On Mon, 16 Jan 2012 03:20:50 +1100, Lloyd Etheridge
<llo...@lretheridge.com> wrote:

>Hans.
>Thanks for the quick reply.
>I havent upgraded as I had not needed to and sometimes upgrading
>software can be a nightmare when you really dont want things to go
>wrong... I do take your point and will look at upgrading it soon.
>
>I tried changing it to what you suggested and still no response it does
>not accept _WINDOWS nor _Windows only the _WIN32.

What response do you expect _WINDOWS to produce? What is supposed to
happen?

If you reveal what the compiler is intended to do when _WINDOWS is
defined, it might be possible to get OW to do it using something else.

The macro _WINDOWS_16 is still used (by windows.h) to distinguish
between 16-bit Windows (win16.h) and OWs 32-bit Windows extender
(_win386.h). The latter does for 16-bit Windows what 386 DOS extenders
do for 16-bit DOS (32-bit Windows programs use win32.h, IIRC).
_WINDOWS_16 is not generated by the compiler either, unless something
has changed in the last few years since I looked at this, and, since
_win386.h /includes/ win16.h, most if not all 16-bit Windows programs
very likely do not need it.

>I must admit I am not that familiar with the compiler as I have been
>more atune to the software result than the method of compiling ..call it
>bad programming but when trying to do a major programming job on your
>own doesnt give you time of day to learn it all. I am amazed at how
>others seem to learn so much and then have to write the program to do
>what this world demands...but thats another story I think.
>
>The script I am referring to is an out of the box copy from VPEDEMO.CPP
>from
>http://www.idealsoftware.com/en/pdf-library/sample-code/overview.html
>and assumed that their sample code was correct but returned the error
>that I had mentioned.

Too bad that link doesn't actually lead to a copy of VPEDEMO.CPP, just
a sample program not showing any macros at all, never mind _WINDOWS.

>I will refer their error to them but wasnt sure it was something that i
>had done wrong or it was within the compiler.
>
>Thanks for your reply I will have to seek advice from the author as to
>what is wrong.
>I have been searching for days a good pdf dll but wihtout paying a high
>price for one there isnt too much around that is simple and easy to add
>via the compiler or its just that I am out of touch with it all, the old
>brain aint what it used to be.

Actually, reading the description, it looks like you may have found
one. If you can get it to compile.
--
"Nature must be explained in
her own terms through
the experience of our senses."

[Lloyd Etheridge]

thanks,

sorry guys I should have posted the sample script online that they gave
me so you could see what I was referring to however I have posted one
there now and yes if I can get it to work its supposed to do all that I
need and more ...
I have uploaded a copy on the web for the C++ sample to view.
http://www.eziaccounts.com.au/software/c++.zip where you can download
and view all the sample code supplied as well as my error file, I hope
this helps anyone else out there trying to write pdfs on a web server.

One of the main reasons I havent updated my compiler as my motto is "if
its not broken dont fix it." as one time I have upgraded only to find
more bugs than I had before and I really dont need the stuffaround at
the moment.

I have created a fairly complete and comprehensive
manufatcturing/accounting/payroll package with it and I would rather
spend more time on the software itself than working out new compilers
etc if you get what I mean.

The brain aint what it used to be to be taking on new stuff at my age
and I just really want to get things up and going and ready to market
more than keep adding.

Anyway...I still appreciate any assistance that I have been given from
this group over the years even though I havent been back to it for a
long time, being a one out programmer has its limitations.

My purpose for creating on the fly pdfs is just for basic standards as
well as an email and html page.

cheers.
Lloyd.

[Uwe Schmelich]

If you only want to create PDF files maybe this is worth looking at:
http://libharu.org/
However, havn't tried it myself yet.

[Paul S. Person]

On Mon, 16 Jan 2012 22:49:17 +1100, Lloyd Etheridge
<llo...@lretheridge.com> wrote:

>thanks,
>
>sorry guys I should have posted the sample script online that they gave
>me so you could see what I was referring to however I have posted one
>there now and yes if I can get it to work its supposed to do all that I
>need and more ...
>I have uploaded a copy on the web for the C++ sample to view.
>http://www.eziaccounts.com.au/software/c++.zip where you can download
>and view all the sample code supplied as well as my error file, I hope
>this helps anyone else out there trying to write pdfs on a web server.

OK, and by opening and actually examining VPEdemo I can see that the
effect of not defining _Windows is to compile for Linux. Have you
tried using -d_Windows with the compiler? Or rather, since you are
using the IDE, by putting _Windows in the "Macro definitions" box on
page 3 of the Compiler switches? Note that case matters here: the
macro is _Windows, not _WINDOWS.

That may or may not work. The problem is that your first error
references a file that is not in the ZIP file. But perhaps that is
only needed when compiling for LINUX.

>One of the main reasons I havent updated my compiler as my motto is "if
>its not broken dont fix it." as one time I have upgraded only to find
>more bugs than I had before and I really dont need the stuffaround at
>the moment.

One of the reasons others will encourage you to update is that any
actual compiler bugs you find may have already been dealt with.

OTOH, OW 1.8 introduced a new C++ compiler. So far as I know, it works
(and we are in OW 1.10 so there has been time to smooth out any major
problems), but I haven't done any C++ programming for quite a while
and so I can understand if you are a bit cautious.

One of the advantages of the new compiler is that (IIRC) it only
instantiates template functions and template member functions (except
at least one constructor and the desctructor) if they are /used/. This
mostly affects 16-bit programming, since the former compiler (the one
you are using) instantiates /everything/ at the earliest opportunity,
such as a typedef, and that results in <string> generating nearly 64K
in code, ie, nearly filling an entire 16-bit code segment. For 32-bit
programming this is less critical, but the new compiler might well
produce smaller executables, unless, of course, you actually reference
every single template member function of every single template class.