Desing Assistance Wanted: Delete Files / Cleanup

[Michael Mattias]

I am creating a desktop application in which I generate a PDF file, and then present the user with a choice of options of what to do with that file:

- View it (using acrobat)
- Print it on named printer
- Fax it to {get fax number here}
- "Save as" for future use
- Send as email attachment to {get email address here}

The user may choose any or all of these options.

I generate this file to the user's application data folder (CSIDL_APPDATA\named subfolder). (I could use the users "GetTempPath" folder, I'm still thinking about this); the program reaches a point where I know, "A PDF file is ready for the user to select the delivery options" and this is where I present a 'delivery options' screen.

My problem is this:

Users will be generating many, many such files during the time the program is running, and I want to "clean up" all these temp files; that is, the only *.PDF files I want left at the end of the day are those which the user chose to "save as."

Right now the only way I can think of to do this is to do some kind of mass delete on WM_DESTROY of the main application window: I can't delete 'em if the user is still viewing thru Acrobat, or printing 'em, because Acrobat is using 'em.

Does anyone have a better idea?

Thanks,
MCM

[Erich Schulman]

And besides the Acrobat reader, someone might be using the Foxit Reader. Or even xpdf. You probably would not be allowed to delete a file while it is still printing. Checking whether the file is open might be reliable enough.

If you can be sure the file will always be on a local drive, compare the file's date/timestamp to the system uptime. If it predates system start, delete it. (But give at least an hour's padding in case someone likes doing their daylight savings time adjustments manually.) This can run when your application starts.

[John Petty]

As I read your description these files should properly placed in the user temp folder and in line with good programming practice all be deleted on closing the program (unfortunately often not done). As you said the only ones to be kept are after Save AS which should default to another folder.
A simple but slower method if you you can (and should for temp files) name them with some unique feature that allows them to be easily identified with i.e. mcm*.pdf, then using DIR$ build an array of their names and the KILL them one at a time.
The documentation of the KILL statement is necessarily vague about killing a file opened in another application as it will depend on how the application opened it, Adobe will lock the file so you will get error 70, if it were a txt file and open in notepad it wouldn't care as it loads the file to its own temp or in memory and doesn't care. That is why they should be deleted one at a time.
Any files missed would get deleted on the next program close or if you wish a decent time delay do it on the next program open.

[Gösta H. Lovgren-2]

Does anyone have a better idea?

Thanks,
MCM

How about deleting them the next day? Or whenever the next time the program runs? Or 1 hour after close of business?

Just quick thoughts.

[Michael Mattias]

I know the 'mass delete' will work, if I just ignore any 'file in use' errors. When the user fires up the program tomorow, I will guess Adobe Reader has long since stopped using that file.

It just seems so darned ugly. No style points.

MCM

[Jeff Blakeney]

I am creating a desktop application in which I generate a PDF file, and then present the user with a choice of options of what to do with that file:

- View it (using acrobat)
- Print it on named printer
- Fax it to {get fax number here}
- "Save as" for future use
- Send as email attachment to {get email address here}

The user may choose any or all of these options.

Why not delete it immediately after finishing the task(s) requested? If the user chooses more than one option, set a counter with the number of options and decrement that after each one finishes and when it reaches zero, delete the temporary file. This may require using threads and starting tasks synchronously because when viewing the PDF with an external program, you need to wait until that program is closed before you can delete the file. Shelling to Acrobat synchronously from a thread would allow your program to do other options and when Acrobat finishes, your thread would continue and decrement the counter and end the thread.

Here's an example. The user chooses to view, print and e-mail the PDF. Your program would set a counter to 3, create a thread to synchronously shell to Acrobat then run a procedure (or create another thread) to print the PDF and then run a procedure (or create another thread) to e-mail the PDF. At the end of each procedure and/or thread, the counter gets decremented. Your code would have to wait for all procedures and/or threads to finish, check the counter to make sure it is zero and then delete the tempoarary PDF file.

Come to think of it, using one of your favourite routines (WaitForMulitpleObjects I believe it is called ) you probably wouldn't even need the counter. Just run through any procedures you want (which all run synchronously) and then wait for any threads you've started to finish and then you are free to kill the file.

[Michael Mattias]

The Synchronous VIEW is not an option. View must launch Acrobat Reader (or whatever is in use for *.pdf files) ASYNCHRONOUSLY... putting the file in use.

For all the other options synchronous is no problem. We estimate VIEW will be one of the options about 106% of the time at first, probably dropping to 99.997% as the users get comfortable with the application.

MCM

[Brian Chirgwin]

Does anyone have a better idea?

Thanks,
MCM

Possible ugly issue
If you are sending email directly from your application, not a problem. If you are doing so via the user's default email program you have to consider how the program works.

I use Pocomail (Outlook might work be different) and I have written apps in the past that bring up a message with an attachment already attached. If I delete the file before queueing the message, the attachment is lost. In other words, the attachment isn't "packaged" into the email until the send or queue button is clicked. It is possible to delete the file before the user writes a note with the attachment. Not sure if this will affect you in your situation, but thought I'd bring it up.

Solution?

This would solve the above as well as any application.

Is it possible to ask windows what file is used by what process?

You could check for each temp file on exit see which have 0 open handles to it and it is deletable. Anything open you wouldn't be able to delete, but you could check on start up. Actually, I think you might have to go the other way. Check each process and see what files the process has open, if it is one of your files, don't delete it. Check out Handle

I'm not sure how this little app works, but pass it the filename and it will tell you what process is using it. So it is possible, just not sure how at the moment. I'll have to look into this solution myself when I get a chance.

[Michael Mattias]

The email is Outlook+Exchange Server.

The idea is, I will launch Outlook's "create new mail" thing with the sender and reciever address and the PDF attachment, and maybe some 'default' subject and/or message text, and the user will add some "personal touches" to the body and then "send."

There are two pieces of code I found here (see "Search") offering two ways in addition to the MAPI I had previously tried (which did not work) to 'send file as attachment'

I do believe once the attachment has been MIME'd the original file can be safely deleted. The only thing I'm not sure of yet is WHEN the attachments are MIMEd: at "attachment time" or at "send time."

But I guess I will find out, won't I?

(Yes, I *am* having a good time creating this. It's been a while since I had the chance to sit down and create a Genuine Real End User Desktop Application).

MCM

[Knuth Konrad]

This somehow doesn't sound "right" to me. It's not the "Windows way" of handling such a situation.

IMHO, both the "View" and "Email to" should imply a "Save As" as it's first step.

So, perhaps the options should look like

[ ] Print it on named printer
[ ] Fax it to {get fax number here}
[ ] "Save as" for future use
     [ ] And view it (using acrobat) (Disabled until Save As is checked)
     [ ] And send as email attachment to {get email address here} (Disabled until Save As is checked)

This way, the user always chose where the file is stored and may or may not delete it afterwards.

[Paul Purvis]

Michael, if i where your user, i would almost certainly not want files being placed at random all over the place by an employee, specially temporary files.

If you place the pdf files near to where the data is located, a backup routine can delete those files before doing a daily back up.
Can windows create a virtual drive in memory, if so and there is plenty of memory or using the SUBST to create a virtual drive that is assigned to a specific directory.

If a user wants to copy the file, then they can, but i am all in favor for restricting a user in most all cases in a business environment.

you can name these files also "michael.pdf.tmp" if you are controlling the pdf reader or if not "michael.tmp.pdf". Then a nice little "DEL /S *.TMP.PDF" will get ride of those files.
the big problem here is the asterisk, do not do a "DEL /S *(SPACE).TMP.PDF" Yikes that hurts to do that.

[Michael Mattias]

This is the "original design" which everyone agreed to.

However, the one person who was left out of this design was, yes, Suzy User.. the one person the client probably should have included in the review.

I fully expect changes. I was just trying to be a nice guy and clean up after myself.

Paul, asking the users to do things is easier said than done. This is going to be used all day long by somewhere between 15 and 35 users, located in Massachusssets, Texas, Indiana, Canada and the United Kingdom.

The info is customer invoices and statements. We really don't want to make "PDF" files of these things just lieing around waiting for one of the other 250 users on the network to scarf them up and email 'em to his/her home. I will be logging who does what with these files WHEN DONE THRU THE APPLICATION, so there is at least some measure of accountability.

Yes, they ARE password-protected, but right now that's only for editing. I think we may have to add a password for viewing, too perhaps one the user enters right on the screen on a per-incident basis.

It's a really cool application, but it IS 'something new' so nobody really knows how the nuts and bolts will have to fit together, or what is going to work out of the box and what is going to need some revision.

you can name these files also "michael.pdf.tmp" if you are controlling the pdf reader or if not "michael.tmp.pdf". Then a nice little "DEL /S *.TMP.PDF" will get ride of those files

The files are actually named by Windows (GetTempFileName), and they all end in ".tmp" Even if I can't delete em all immediately, it's unlikley anyone will ever figure which of the five (5) to nine(9) randomly-named files created on each run is actually a "Portable Document File."

But since I can control the first three characters of those file names, that does open up some 'mass delete' possibilities.....

(This really IS fun!)

MCM

PS:
"DEL /S ..." is so, so....Philistine!

[Jeff Blakeney]

The Synchronous VIEW is not an option. View must launch Acrobat Reader (or whatever is in use for *.pdf files) ASYNCHRONOUSLY... putting the file in use.

You are right, using a SHELL statement won't work. I just did the following test code:

FUNCTION PBMAIN

    SHELL "C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe C:\displayStandings.do.pdf"
    MSGBOX FORMAT$(ERR) + $CRLF + ERROR$, , "Done"

END FUNCTION

If Reader isn't running when I execute this program, it works as I expect. It doesn't display the message box until the I've closed Reader.

However, if I simply close the file in Reader, and leave Reader running, then my message box still doesn't get displayed until I've actually closed Reader.

My final test was to have Reader already running and then execute the program above and the already running Reader opens the file no problem but my program immediately displays the message box.

So it looks like you might need to use Brian's advice and check to see if the file in question is opened by anything else and when it isn't, then you can delete it.

[Scott Slater]

Why not mark it for deletion on next reboot?

#Include "Win32Api.Inc"
...
   
   Local KF As Asciiz * %MAX_PATH
   
   KF = "C:\Some File to Be Deleted.ext"
   
   MoveFileEx KF, "", %MOVEFILE_DELAY_UNTIL_REBOOT

[Michael Mattias]

> Why not mark it for deletion on next reboot?

Oooh, oooh... delete on reboot..... good idea!

>You are right, using a SHELL statement won't work

Who cares if it works or not? YOU GET ZERO STYLE POINTS!!!!

MCM

[Michael Mattias]

UPDATE:

On the file delete, I took the WMD approach and at several convenient points in the program I just delete files using "KILL <prefix>*.*" approach, except for the attached PDF file .... because I have not yet tested "when is Outlook done with the attached file" thing.

Which brings us to.....

I have the software working exactly as described above .. my program ends up displaying the user's regular Outlook "new mail" screen with the subject, body and recipent filled in and the attachments attached. So far it works with at least Outlook 98 on Windows NT4* and Outlook 2003 on Windows/XP (this *is* the Real World, you know).

I intend to create and post a simple demo of this soon, when I get the "when can I delete the underlying attachment files safely" fully tested.


To get this to work, I created the followning...

' Generated by: PowerBASIC COM Browser v.2.00.0070
' Date & Time : 10/21/2009 at 2:27 PM
' ------------------------------------------------
' Library Name: Outlook
' Library File: D:\Testdata\msoutl8.olb
' Description : Microsoft Outlook 8.0 Object Library
' Help File : D:\Testdata\VBAOUTL.HLP
' Help Context : 0
' GUID : {00062FFF-0000-0000-C000-000000000046}
' LCID : 0
' Version : 8.0
 [ Many many many more lines] 
...

I was wondering, is there a COM interface for Outlook Express?.

I use OE but darned if I can find among the 643 registered libraries the COM Browser finds on my system anything which looks like an "Outlook Express interface"


MCM
*BTW this version of the COM browser will not run on NT4 for want of an import not available until Win/2000. PB Support sent me an update, but I haven't tested it yet.

[John Petty]

UPDATE:

On the file delete, I took the WMD approach and at several convenient points in the program I just delete files using "KILL <prefix>*.*" approach, except for the attached PDF file .... because I have not yet tested "when is Outlook done with the attached file" thing.

You mean you finally read post #3

Which brings us to.....

I have the software working exactly as described above .. my program ends up displaying the user's regular Outlook "new mail" screen with the subject, body and recipent filled in and the attachments attached. So far it works with at least Outlook 98 on Windows NT4* and Outlook 2003 on Windows/XP (this *is* the Real World, you know).

I was wondering, is there a COM interface for Outlook Express?.

I use OE but darned if I can find among the 643 registered libraries the COM Browser finds on my system anything which looks like an "Outlook Express interface"

This is a real problem area and many commercial programs fall down on it. You have to use MAPI and that only works from version 4 onwards (or after version 4 forget which), but before that you need to detect the users default mail client which maybe either (as express is installed by default and OE by default in Office) or a third party email client.
The only real "cover all situations" is to write your own email sending program (not hard). In the end it comes down to where the email is saved as a sent item if that is needed. One of the largest accounting software companies has that problem, it puts the sent email in outlook express so if you are using OE or something else you need to open Express to see what has been sent.
My solution, as the recipient is already known (I assume email address), is to send them with a DLL (many free ones and demos here, but I use my own) which can if required display email details and if required save them. Should the sending fail externally then the failure message is sent back to the users From Address which is then received by their default mail client so not missed.
For OE it moves a copy of the attachment to the PST file or Exchange server as soon as it is asked to be sent so the original can be safely deleted after that point.

[Michael Mattias]

So that would be a 'NO' on OE via COM?

[Knuth Konrad]

I've never heard of OE exposing itself via COM. So it is a "NO".