Jump to content
Sign in to follow this  
henryp

DirRemove Does not run

Recommended Posts

henryp

Scenario:

Uninstall program #1

Uninstall Program #2

DirRemove Program #1's left over files

DirRemove Program #2's left over files

Every time i run this, Program #2's files are never deleted.

When i put a sleep(1000) then everything will work successfully. I dont want to rely on the sleep time to DirRemove successfully.

So is there a way to have my program work all the time? Is there some sort of wait i can use for the DirRemove and uninstalling program #2?

Share this post


Link to post
Share on other sites
LurchMan

Can you post your code so we can see what you're working with?


Dating a girl is just like writing software. Everything's going to work just fine in the testing lab (dating), but as soon as you have contract with a customer (marriage), then your program (life) is going to be facing new situations you never expected. You'll be forced to patch the code (admit you're wrong) and then the code (wife) will just end up all bloated and unmaintainable in the end.

Share this post


Link to post
Share on other sites
electrico

Man if you want real help post your code.

Anyways, you can use this:

FileDelete(@DesktopDir & "\Directory\*.*")
DirRemove(@DesktopDir & "\Directory")

Or if directory is not removed anyway, so that means that this directory is locked by other process, may be windows msiexec.exe or explorer.exe. So try to do this:

ProcessWaitClose("msiexec.exe")
;ProcessClose("explorer.exe") - Here I put comments because it may be not so necessary.
;ProcessClose("rundll32.exe") - the same thing...
FileDelete(@DesktopDir & "\Directory\*.*")
DirRemove(@DesktopDir & "\Directory")
;ShellExecute ("explorer.exe") - in case u have killed explorer before to remove directory.

Edited by electrico

Share this post


Link to post
Share on other sites
sleepydvdr

Just to comment on what electrico said, that is correct. Background processes may have a lock on files/folders but just remember that killing background processes and restarting them can mess up what a user is doing. All of the users' open windows will be closed and if that person is doing something such as copying a large file to their computer, the transfer will stop and fail. I would not rely on this method to solve the problem. Your original sleep solution would be better.


#include <ByteMe.au3>

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.