Tracy,

I'd suggest keeping an internal list of files added to the temporary directory, and deleting based on that list.

Two reasons for this:

1. If you ever end up using a shared directory, other people might have files in there that you don't want to delete early.
2. It's a lot quicker if you don't have to go find out what files exist in the directory. It also means you can determine what order to delete them in (if that's an issue), and whether or not you want to selectively NOT delete some of them (debugging).

Along with number 1, making sure you have unique temp filenames should be taken into consideration as well.

*** this was supposed to be a response to Brad's suggestion of keeping a list and delete just the list.  

the downside to this approach (of keeping your own list) is that if your application crashes then those files that were created in that session won't be deleted. I use this exact approach of delete only the list, and i see left over files from crashes.

maybe a combination of both approaches if speed really is a concern.

there are windows apis to get the files in a directory. its stupid that we have to drop down to api's for something like this rather than have a PB native command.

If it's just a scratch directory, I'd use Roland's RunAndWait to run the DOS command

rmdir <directory> /s /q

To clean up after a crash, you can also run the command when your app starts up.

Hi Tracy,

To your question of wildcards in FileDelete(), no the file must be specifically named. I do like what Brad has suggested in his first reply as it gives you some options and flexibility in the event that's important to you and I have used it on occasion. If that's not important to you and you are confident and comfortable deleting an entire directory and all it's contents then, as Chris suggested, issue a DOS command with the Run() function. More specifically, the syntax would look something like this:

Run('CMD /C "RMDIR /S /Q D:\MAIN_FOLDER\sub_folder"', Minimized!)

The /C is to ensure the CMD window terminates. The /S is to include all subfolders and files and the /Q is to prevent the "Are you sure..."
prompt.

Respectfully, I'm less concerned about the safety issue that Brad raises about deleting the wrong directory as well as the concern about interacting with the DOS command for the following reasons:

1) You're already keeping track of the temporary directory and so that would be explicitly stated in the Run() function; should the temporary directory not always be the same or the same full path (EG different users), or you want the flexibility to change it, such that you can't hardcode it in the Run() function then simply build the string for the Run() function using a string variable...so unless I'm misunderstanding Brad's concern, I can't see how you would accidentally delete the wrong directory/ files. My approach has always been to rely on PBScript first in order to accomplish something but I wouldn't hesitate to utilize shelling out to DOS or using Windows API calls if the need/ preference arises.

2) Per the /Q option above (which also works with Del *.*), this will prevent the DOS confirmation prompt and so eliminates any user interaction

As Mike and Miguel have suggested, there is the potential for this to go sideways should there be a crash of the application but I think you can plan for this by ensuring that when you first create the temporary folder it doesn't already exist and if it does then delete it using the same approach as above. Of course, that depends on how you are naming the temporary directory...is it always the same name but maybe a different path per user? Is it always a different name that you're randomly generating but in the same path? Are you coding for multiple users for this functionality? The danger with randomly generated directory names is, over time with multiple crashes, you'll accumulate many orphaned directories/ files that will never be deleted unless you manually look after these after each crash.

HTH...regards,

Mark