Stephen
I would consider it an honor to have my name linked to your work. By all
means if you think it helpful, please go right ahead. In the mean time I
eagerly await the release of your next version. Please do give me a heads
up when you release the new code.
I didn't realize you had the DynaPDF source. If you can get all of the
Snapshot - to - PDF logic into a single DLL then you are really cookin'.
You will have commercially viable product that could bring in revenue until
MS releases the next version of Access. Based on what I see in the press, I
expect in the next release we will get at least some kind of direct report
to PDF capability.
However not everyone upgrades. I no longer have any Access 97 customers,
but I continue to do all of my Access development in A2K so I can reach the
largest possible audience with a single code base. Should the next version
of Access be binary compatible with A2k I would be VERY hesitant to change
my development platform.
--
Ron W
www.WorksRite.com
"Stephen Lebans"
wrote in message ...
Hi Ron ,
that looks like a good option. With your permission, I'll add your
method/logic/comments to the next release and the ReportToPDF web page.
I've had my head stuck in Structured Storageup tech papers the last few
days. I finally found some very old code I could work with. I created a
simple Windows System DLL last night and the modified code seems to work
in
prelim testing.
I added the Boolean param to signal; whether to open the created file in
the
registered PDF viewer or not. I also added another param but cannot
remember
what it was right now...getting older.
Will be a new release shortly.
I am considering rediscovering my way out of date C++ skills to create a
customized version of the DynaPDF library. This way I could include all of
my current Access code/logic directly within the DynaPDF DLL. I would then
use the same logic you posted, create the Snapshot and then pass the
Snapshot to the ConvertReportToPDF function. No MDE required, no mess, no
fuss!
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Ron Weiner" wrote in message
...
Stephen / Silvester
Here is a test function that seems to work well enough. BEWARE this is
just
a test of automating Stephens MDE without having to set a reference to
it.
I
have all of the file locations, and report names hard coded.
I think calling Stephens function this way opposed to setting a
reference,
makes the calling application less prone to fail, and requires much less
end
user intervention to get the app working should a failure occur.
In the real application I plan to have the full filespec to Stephens MDE
in
a table where I can do a simple Dlookup, and make changes in a
heartbeat.
The Report Name, Temp SnapShot, and Output PDF filespecs will be passed
from the caller. The function returns the filespec of the PDF on
success
and an empty string should an error occur.
Public Function Rpt2PDF() As String
Dim o As Access.Application
On Error GoTo Err_Rpt2PDF
Set o = New Access.Application
o.OpenCurrentDatabase "C:\PPI\ReportToPDF.mde"
DoCmd.OutputTo acOutputReport, "rptProject", acFormatSNP,
"C:\PPI\ddd.snp"
o.Run "ConvertReportToPDF", "", "C:\PPI\ddd.snp", "c:\Z.pdf"
Kill "C:\PPI\ddd.snp"
Rpt2PDF = "c:\Z.pdf"
Err_Rpt2PDFOut:
If o.CurrentObjectType 0 Then
' Appears to always be -1 when OpenCurrentDatabase fails
o.CloseCurrentDatabase
End If
Set o = Nothing
Exit Function
Err_Rpt2PDF:
Rpt2PDF = ""
Debug.Print Err.Number, Err.Description
Resume Err_Rpt2PDFOut
End Function
If only I could keep Acrobat from opening with the new PDF file, I would
be
in "Super Fat City", where all the girls are pretty.
--
Ron W
www.WorksRite.com
"Ron Weiner" wrote in message
...
Stephen
I have (after much experimentation) found the cause of my problem. It
appears to be the Printer Driver I was using (HP LaserJet 1200 Series
PCL
6)
was the culprit. I changed the print driver to a plain vanilla HP
LaserJet
4 and **poof** no more errors. PDF's are created as per the
documentation
in your MDE.
However, as long as this is beta I wonder if you might consider making
a
change or two.
1) It would be nice if there was a way to keep Acrobat from opening
each
time a pdf was created.
2) It would be nice if we could pass both the report Filter and
report
Where condition as parameters
3) It would be nice if we could specify the name and location of
the
temp .snp files (I have a bunch temp files hanging around from all of
the
failed attempts I have made.
4) Could you distribute the MDE with NO Forms or Reports in it, in
an
effort to keep it as small as possible.
Of these three the first one is the most important to me. Most of the
time
I am making a PDF just to Email it somewhere. There would be no need
to
open the PDF viewer, the sender would already know what was in the
report
as
they will have likely previewed it before sending the email.
If you are looking for testing help as you move your Beta along please
feel
free to contact me. I would be happy to help.
As for an independent solution, I have always liked the idea of having
full
control over how my app is going to work. I would be more than happy
to
use
your solution as you have it (abet the change for opening Acrobat after
PDF
creation), but I am concerned about adding a reference to my mde's. Is
there any way I can use something similar to late binding with your
mde.
I
am sure that I will get a support call some day where the client has
done
something that caused Access to forget that it had a reference and stop
making PDF's. If I were able to use some sort of late binding
technique
that support call could take a lot less time and effort.
Anyway thanks for your time and all the help you have provided to me in
the
past. It is and has always been most appreciated.
--
Ron W
www.WorksRite.com
"Stephen Lebans"
wrote in message ...
While it's Beta release, I have not heard of any problems with the
A2K
release.
There is an issue which I have publically mentioned a few times and
is
the
same issue you are experiencing. It happens with unbound reports and
reports
that are not formatted correctly to fit on the selected output
page(margins
too large, paper too small etc.). I won't repeat here the lengthy
Structured
Storage issue that is the cause of the above issues. The solution is
to
use
a third party ActiveX control which I simply do not want to do
because
of
distribution/registration issues. I am working on new logic to parse
the
Structured Storage file which I will incorporate into the next
release
shortly.
But you should not be seeing this bug if you are using your own
reports
or
have converted my reports(Letter size) to your own page size. Can you
send
me one of your reports that fails?
I cannot make the source of the MDE available because:
1) It contains the License Key for the DynaPDF library.
2) It will shortly contains intellectual property that I signed a non
disclosure agreement to gain access to.
So at this point, I will not be able to release my source code.
Ron why do you need to come up with an independant solution?
--
HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Ron Weiner" wrote in message
...
Stephen
This post lead me to your site to have a look at your solution, as
I
have
yet to find an adequate one size fits all method of creating PDF's
from
Access. Virtually every customer I have is using different PDF
creators,
or
different versions of the same software, all of which seem to have
idiosyncrasies. I am forever having to tweak this and change that
to
make
things work. What's worse it makes me look as if I do not know
what
the
heck I am doing. This is something that OUGHT TO BE EASY to
implement,
but
trips me up almost all of the time.
This solution looks VERY promising and I am willing to buy the
DynaPDF
tool
if I can get the glue you used to hook Access Reports and Snapshots
up
to
it. I have downloaded their Eval an looked at the documentation
and
VB
examples. I find that is architected similar to but with much more
control
and complexity than a Package I already own (DynammicPDF). The
fact
that
it
is an Xcopy install makes it even more interesting.
I am having problems with the Access2K version that I downloaded
from
your
site. It complains:
fCreateSnap.fParseSnap:-2147220958
Sorry...Page size not supported
Please select a different Report to Export
No matter what I throw (Report or existing Snapshot) at it I get
this
same
message. I have tried using it directly from the example you
provided
in
the mde, and as an external library to one of my projects. I
thought
perhaps a problem with A4 vs. Letter Page setups, but no joy.
So I guess the questions a
1) Is there a known problem with the Access 2K version
2) Are you willing to share the Access to DynaPDF source WITHOUT
the
DynaPDF License Key
3) Would you be willing to give us a hint of how the glue works
so
I
could attempt to come up with an independent solution.
From my short observation it appears that you may be parsing a
snapshot
of
the report, and translating the objects that you find there, into
calls
to
the DynaPDF library. Can you point me to any good documentation of
how
to
parse the snapshot format? I would most appreciative of any help
you
can
provide.
Thanks
--
Ron W
www.WorksRite.com
"Silvester" wrote in message
...
Hi,
With reference to Stephen Lebans interesting report to PDF
solution
found
at
http://www.lebans.com/reporttopdf.htm
If reference is set to the provided mde and the app is distributed
along
with the mde & dll in the app's default directory, will I run into
broken
reference issues on end user machines?
Basically I'm asking how to set up references to this mde so that
it
can
be
safely distributed.
TIA