Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / December 2005

Tip: Looking for answers? Try searching our database.

Sending report to a PDF File.  Good link for Access developers

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
salad - 16 Dec 2005 18:41 GMT
Hi Guys:  I was stuck.  I needed to send a report to a file.  My
beautiful report(s) in Access were going to require loss of formatting
with RTFs, a PITA in WordMailMerge, sending it as a text file...whatever.

I described my situation to the guy I'm doing work for and he did some
research for me and came up with the following link.

http://www.novapdf.com/

The part that should excite us Access developers is their SDK
http://www.novapdf.com/pdf-sdk.php

And as an Access developer, you might faint at
http://www.novapdf.com/pdf-reports-access.php

You can use the SDK and not spend any cash (free).  It will simply put a
Novapdf watermark on the document.  But if you are distributing your
application to others, the SDK can be purchased and the watermark goes
away.  So if you are distributing apps, you might look at this product
with interest.

I'll test it out and post my observations on it...most likely in the
beginning of 2006.

Frankly, for my needs, this is an early Christmas present if it works as
advertised.
MLH - 16 Dec 2005 19:04 GMT
Am looking forward to your evaluation.
salad - 16 Dec 2005 20:09 GMT
> Am looking forward to your evaluation.

Great.  I hope I have something very positive to report.

I like their statement " novaPDF SDK is fully functional with no time
limitation. This means that you can download, install, integrate it in
your application and test to see if it fits your needs, without ordering
it."

Can't get better than that.
MLH - 16 Dec 2005 19:06 GMT
Have you looked at stephan lebans' A97SnapshotToPDFver746.mdb?
salad - 16 Dec 2005 20:07 GMT
> Have you looked at stephan lebans' A97SnapshotToPDFver746.mdb?

No I haven't.  However, if it would require a 2 step process to create
my document (first snapshot then convert to pdf) I would prefer a single
step method.

I would liked to have used the snapshot format in a report recently but
it is virtually useless with graphics.  Maybe the snapshot format can
use graphics, but from my experience they need to be tiny.
Stephen Lebans - 16 Dec 2005 22:04 GMT
The conversion process does require exporting the Report to Snapshot format
first but it is performed programmatically. It does not require the external
MS Snapshot viewer just the native Access ability to export to Snapshot that
exists from A97 SR1 and later. I have not seen any significant Image related
issues with conversion to Snapshot from A2K on and I have tested hundred's
of reports. Your experience is not the norm.

I purchased the DynaPDF library and negotiated rights so that it could be
distributed as a Freeware solution. PDF conversion is performed within a
standard C++ DLL that does not require Registration or a Reference be set to
the DLL. No PDF printer driver is required. This is important to me as I
want to limit the amount of tech support required for this solution.

I am slowly exposing more functionality of the DynaPDF library. Compression,
security, combining multiple PDF docs etc.. Early next year I should be able
to display a PDF document within an Access Form/Report without requiring and
ActiveX or OLE Frame control.

I am not espousing that my PDF solution is the best. For most people, and
especially single users, a PDF Printer Driver is by far the simplest and
easiest solution to implement. But for corporate desktops that are locked
down tight, my solution is a very attractive alternative. For developers
that want/need control over the conversion process, again my solution is an
viable alternative. For Developer's that require complete control they can
simply purchase the DynaPDF library directly.

Signature

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

>> Have you looked at stephan lebans' A97SnapshotToPDFver746.mdb?
>
[quoted text clipped - 5 lines]
> is virtually useless with graphics.  Maybe the snapshot format can use
> graphics, but from my experience they need to be tiny.
salad - 17 Dec 2005 01:25 GMT
> The conversion process does require exporting the Report to Snapshot format
> first but it is performed programmatically. It does not require the external
> MS Snapshot viewer just the native Access ability to export to Snapshot that
> exists from A97 SR1 and later. I have not seen any significant Image related
> issues with conversion to Snapshot from A2K on and I have tested hundred's
> of reports. Your experience is not the norm.

Yeah.  My computer is not the norm.  I once had A2K on my machine and
removed it.  It affected somthing in A97 where I couldn't export/import
text files.  So I removed Office97 from C:\Program Files\Office97 and
reinstalled to C:\Program Files\Office or whatever the default is.  This
created even more problems.  Finally I reinstalled Office2k, removed it,
removed A97, went through a laborious process of removing Access97 and a
bunch of registry entries, then reinstalled Office97.  I was able to
install SR1 but SR2 refuses to install.

Today, I can't create Snapshot files even tho I have SR1.  I guess I
could do that if I were to reformat my drive, reinstall Windows,
repurchase programs I purchased over the net but I won't.  If I were to
go through all that rig-a-marole I'd buy another computer instead.

I simply disappointed in MS ability to run a clean uninstall.  And I'm
disappointed in MS's inability to communicate well with their other
programs.  I guess the registry is so complicated even they can't clean
 up their things right.

> I purchased the DynaPDF library and negotiated rights so that it could be
> distributed as a Freeware solution. PDF conversion is performed within a
[quoted text clipped - 6 lines]
> to display a PDF document within an Access Form/Report without requiring and
> ActiveX or OLE Frame control.

That will be wonderful!

> I am not espousing that my PDF solution is the best. For most people, and
> especially single users, a PDF Printer Driver is by far the simplest and
[quoted text clipped - 3 lines]
> viable alternative. For Developer's that require complete control they can
> simply purchase the DynaPDF library directly.

I wish you much success.
Arno R - 16 Dec 2005 19:44 GMT
> Hi Guys:  I was stuck.  I needed to send a report to a file.  My
> beautiful report(s) in Access were going to require loss of formatting
[quoted text clipped - 22 lines]
> Frankly, for my needs, this is an early Christmas present if it works as
> advertised.

I also need to send my beautiful Access-reports to others.
I use PDF995 to generate the pdf-files with very good results (also free, NO watermark)
The only 'nag' if you like with the free version is that you are linked to their website.
If you don't like this you have to spend some money ($9,95)

It suits my needs allright.

Arno R
salad - 16 Dec 2005 20:03 GMT
>>Hi Guys:  I was stuck.  I needed to send a report to a file.  My
>>beautiful report(s) in Access were going to require loss of formatting
[quoted text clipped - 32 lines]
>
> Arno R

What I like about this is that I, as a developer, don't have to worry
about other PDF writers any user may have.  I won't need to charge
licensing fees or demand someone have a certain writer.  For the cost of
Adobe, I have something that is specific to my app.

If you are at a fixed site, or with a company that has
authorized/dictated using a specific writer, then I would stay with your
method.  If you are distributing an application, I would not use your
method.  I don't want to be telling clients that they must cough up
$9.95 for an app for my app to work.  The less I involve my
clients/customers with external issues, the better.
Randy Harris - 16 Dec 2005 20:45 GMT
> >>Hi Guys:  I was stuck.  I needed to send a report to a file.  My
> >>beautiful report(s) in Access were going to require loss of formatting
[quoted text clipped - 43 lines]
> $9.95 for an app for my app to work.  The less I involve my
> clients/customers with external issues, the better.

I looked at their web site.  The purchase price is what I would consider
very reasonable.  If it's as good as they say it is, it's a bargain.  They
have volume pricing (even better discounts) but I didn't see anything about
restrictions on redistributing the licenses to clients.

I too will be looking forward to the results of Salad's evaluation.

Signature

Randy Harris
tech at promail dot com
I'm pretty sure I know everything that I can remember.

salad - 17 Dec 2005 00:59 GMT
>>>"salad" <oil@vinegar.com> schreef in bericht
>
[quoted text clipped - 60 lines]
> have volume pricing (even better discounts) but I didn't see anything about
> restrictions on redistributing the licenses to clients.

Bingo!

> I too will be looking forward to the results of Salad's evaluation.
Albert D. Kallal - 17 Dec 2005 00:02 GMT
First, why use something with a water mark?

For at least two years, I used the following:

It is absolutely Free,

And free means no watermarks, no nag screens, no annoying Popup
advertisements, no time limits etc.

It is also very fast, and works very well. I highly recommend it.

http://www.acrosoftware.com/products/cutepdf/Printer.asp

However, the above does not allow automaton.

(that means you can' use code to set the "output" file.

If you need to "set" the resulting output file?

Well, then...

Right now, the best "free" ms-access report to pdf on the web is of course
Stephen Lebans solution.

Stephen's solution DOES NOT require you to install a printer driver.

the code to make a pdf looks like:

  DoCmd.OpenReport "tblpubs", acViewPreview
  Reports("tblPubs").Visible = False
  Call convertreporttopdf("tblpubs", , "c:\t.pdf", False, True)
  DoCmd.Close acReport, "tblPubs"

Note how the user does NOT have to type in a resulting pdf name. So, with
Stephens code, you don't have to convert, or even install a pdf Printer on
the system.

So, you just open the report as you want...and then call the routine to make
a pdf out of that report....

As far as I can tell, for a free solution, Stephens is better then anything
else out there by a country mile...

You do NOT have to install a printer driver for this to work...

Signature

Albert D. Kallal   (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com
http://www.members.shaw.ca/AlbertKallal

salad - 17 Dec 2005 01:09 GMT
> First, why use something with a water mark?
>
[quoted text clipped - 40 lines]
>
> You do NOT have to install a printer driver for this to work...

I have CutePDF too.  The lack of ability to send if to a specified
filename and the hassle of clicking and pointing to folders using a
File/Open dialog immediately turned me off.  If I could simply specify
CutePDF as the printer for the report, plus give it a file name (use an
ini file in their folder) that would be great.  I DON'T want to force my
users to click and clack to get to a folder, nor do I want them to type
the filename.

CutePDF or PDF995 may be fine if it's for you or for a small company.  I
think, no...I believe one needs a more professional solution if you have
any plans on distributing an app that will make use of writing PDF files.

I would go with Stephen Lebans program except that when I used "Snapshot
format" it clunked and clanged and then burped on an image file I
absolutely needed to have in the report...simply because the image file
was large.  IOW, I needed something more robust than Snapshot.  Reading
Stephen's response, his product will be just what Access developers will
need/want in the future.
Stephen Lebans - 17 Dec 2005 01:27 GMT
Salad just for your own knowledge base, if you are having trouble with
loading a specific image here is some info that may be of use to you.

Here is a NewsGroup post of mine containing code showing how to convert the
contents of the Image control to a Bitmap file prior to printing. This helps
alleviate the "Out of Memory" error that can popup when printing image
intensive reports.

 From: Stephen Lebans (StephenLebans@mvps.org)
     Subject: Re: Reports with potentially 1000's of images
     View: Complete Thread (5 articles)
     Original Format

     Newsgroups: microsoft.public.access.reports
     Date: 2002-11-13 13:16:03 PST

Hi Steve, I would add two other items.
1) Turn of the "Importing Image" dialog window via the registry keys as
outlined here:
http://www.mvps.org/access/api/api0038.htm
Make sure you do it for all Image types that you using that contain the
key.

2) Change all of the Images to Bitmaps at runtime. I have been able to
print previously unprintable reports by doing this last step. Here's a
previous post of mine on the subject.

From: Stephen Lebans (StephenLebans@mvps.org)
Subject: Re: Images in Reports
View: Complete Thread (18 articles)
Original Format
Newsgroups: microsoft.public.access.reports
Date: 2002-09-16 18:46:39 PST

Bruce I finally got a chance to test your method last night. It helped
but only with the actual printing and not the Print Preview itself.
I was able to print the failed Report directly to the printer or to a
disk printer file so that's great! Don't get me wrong, it's still a good
thing because at least you can print the report!

Unfortunately Acess still runs out of resources when you page back and
forth through Print Preview.
I plan to spend some time onthis issue shortly.
Here is the code I use to convert any Jpeg, Gif, or Metafile into a BMP.
Rather than using one of my API solutions I have cheated and set a
Reference to Standard OLE Types type library in order to get at the
SAVETODISK method. But no ActiveX controls are required

Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)

Private ctr As Long

ctr = ctr + 1

Select Case ctr
   Case 1
    Me.Image10.Picture = CreateBitmapFile("C:\A.jpg")

   Case 2
   Me.Image10.Picture = CreateBitmapFile("C:\b.jpg")

   Case 3
   Me.Image10.Picture = CreateBitmapFile("C:\c.jpg")
   ctr = 0

   Case Else
   ctr = 0

End Select

End Sub

Private Sub Report_Open(Cancel As Integer)
ctr = 0
End Sub

Private Function CreateBitmapFile(fname As String) As String

Dim obj As Object

Set obj = LoadPicture(fname)
If Not IsNull(obj) Then

SavePicture obj, "C:\SL11-52"
DoEvents
End If

CreateBitmapFile = "C:\SL11-52"
Set obj = Nothing

End Function

Keywords: out of memory report convert Jpg Jpeg bitmap

Signature

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

>> First, why use something with a water mark?
>>
[quoted text clipped - 59 lines]
> Stephen's response, his product will be just what Access developers will
> need/want in the future.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.