Closing a .pdf

"reference to the hWnd of the pdf "

How does that work?
 
It's brutal means to kill a window. You do not want to do that, honestly, because it will entail embedding calls to Windows API which then depend on whether 32 or 64 bits etc etc.

And the rest of your acronyms just wooooooshed by and left no trace - apparently I have not visited a business like yours :D
 
Some other thoughts.

Rather than move the file, you should be able to copy it to the new destination then have a separate process that periodically attempts to delete the original file in the original location if it already exists in the new location.
First, attempt to move the file, if it errors, copy the file across, and create an entry in your db to indicate that it should be part of the files that should be periodically checked for file deletion. Or after copying the file across, and since it's a read-only pdf, a hard-delete should be possible using command prompt's DEL or ERASE command (with the appropriate hard-delete switch).

To close the pdf you can use command prompt's TaskKill command:
Code:
TaskKill /FI "WINDOWTITLE eq [COLOR="blue"]FileName[/COLOR].pdf[COLOR="red"]*[/COLOR]"
All of these command prompt commands can be initiated from within Access using VBA.Shell()
 
Well the entire idea of having the file open for human perusal is redundant if one can read the contents, hence closing/killing it is irrelevant since the file does not get opened :D
 
Coping it and pasting I can do real easily and then set up something that runs every morning to delete things that are already moved, I will add this today so it takes care of the initial issue. That a great idea.

But then I will start working on just reading in the information from the .docx and get the whole thing automated.
 
Well the entire idea of having the file open for human perusal is redundant if one can read the contents, hence closing/killing it is irrelevant since the file does not get opened :D
Sure thing! A fully automated routine wouldn't require opening the file. The suggestion was just a workaround to the current problem in the meantime.

Looks like aaronb50 will soon begin working on reading from the Word doc. :D
 
Ok so I fixed the issue of not being able to close the .pdf by just having it try to move the .pdf to a temp folder before it does anything else and if an error comes up I tell them to close it.

I've been playing with these pdf a lot the last few days and can basically do anything I want with them now. I do have to go back and ask my original question.

I can:
Move a pdf
Rename a pdf
Read data from a pdf
write data to a pdf
Delete a pdf

Are we sure I cant just close one?

Also, instead of printing the Word Doc to get stamped by QA and then scanning the pdf back in, I have created a program with a front end that lets our QAs select documentation from a drop down. Once selected, the pdf pops up, they digitally sign it and save it in the same location on the server. All of the formatted pdf fields are preserved and I full access to all the information on them.

I'm really interested in how does pdf read our badges for the digital signature? We have to put in our pin an everything.

How does that work? And can I do that with Access?

For a few of my programs I just created a digital signature that I stand by is just as authentic as a pdf signature (since you have to log into the program) but if I can make it so they have to use their badge to sign off that would fall more into the excepted standard way of how a digital signature works. Around here anyway.
 
Last edited:
Is there an activex control for pdfs? Can you open the pdf inside of an Access form? I can't explore it on this computer. For the digital signature part, are you just using a pin, or are you using a token, like a digital card reader? If you are, then I think it works the same as the PKI system, where your private key is on the card, and you use your password to use it. The public key is known so your signature can be identified as you.

edit-If there is an activex control for pdfs, think long and hard before committing to it. Those controls can have different paths on different computers, which will break an mde. If you're not using an mde, then you can modify the references at run time and no harm no foul.
 
To open other files or programs I have been using.........

Code:
Application.FollowHyperlink "pathToFile"

......... and this has worked great till now.

After QA digitally signed the pdf I needed them to save the form in the deflate location that it was opened up in. But using the above code, the current location the pdf was opened up in was not the default location.

But using........


Code:
Private Declare Function ShellExecute Lib "shell32.dll" _
Alias "ShellExecuteA" _
(ByVal hWnd As Long, ByVal lpszOp As String, _
ByVal lpszFile As String, ByVal lpszParams As String, _
ByVal LpszDir As String, ByVal FsShowCmd As Long) _
As Long
 
Call ShellExecute(0&, "open", "PathToFile", strParam, "", SW_SHOWNORMAL)

........ opens the pdf and when the save as screen comes up after digitally signing it, the default location to save is now the correct place. The location the file was opened in.

For the digital signatures themselves, I start with the .docx, convert it to a pdf and then use the pdf tools to add a digital signature. When you click on the signature to sign, you have to have your card in the card reader. You have to select your signature and then enter you pin that is associated with your card. I'm thinking if some code inside pdf can check your card to make sure the pin is correct, it cant be that much of a secret squirrel process and maybe I can do the same thing with Access.
 
Galaxiom knows stuff about digital signatures, but is a bit out of timewise sync with you. There might be a post in this thread by him by your tomorrow, or else you could PM him.
 
I can wait.

Anyone who counts has bought off on my created digital signature in Access so its not a pressing issue.

It's more of I believe it can be done thing, and if it can, I'd rather do it that way.

I'm not seeing anything on Google about it.
 

Users who are viewing this thread

Back
Top Bottom