Permission denied on file deletion and previously copied in VBA - vba

Facing one issue....
Basically, I have a bouton on Word to launch a macro treatment. This treatment saves the open file, copies the open file from C:/ to Z:/, writes an XML file in Z:/, launches another treatment that will read both files in Z:/ and then, clears the files in Z:/.
C:/ is my local computer, Z:/ is a shared drive...
I managed to copy the file from C:/ to Z:/ with :
fsoObject.CopyFile ActiveDocument.Path & "\" & ActiveDocument.name, "Z:\" & ActiveDocument.name, True
Treatment goes well, but I'm completely unable to delete the file in Z:\ with this :
fsoObject.DeleteFile "Z:\*", True
I always get "Permission Denied"... Cannot delete it manually as well, except if I close ENTIRELY Word (and not only the file that was copied)...
Is there a way to avoid the file locking by Word ?
Thx !

Use a vba command to close the file after you have performed your operations. Then apply the delete command.

Related

Word VBA Documents.Open deleting files in folder when falsely passing that folder's path instead of file path

I encountered the following issue:
When accidentally passing a folder path to the Documents.Open function in VBA Word I get the runtime error 5174 as one would expect.
However all files with names that begin with an underscore get deleted in that moment from that folder.
To replicate:
Assume folder C:/Test/
In said folder have two files:
test.txt
_test.txt
In Word VBA execute the command:
Documents.Open("C:/Test/")
(As part of a subroutine or in the immediate window.)
Result: Runtime Error 5174 and _test.txt is now missing.
Note: Passing a nonexisting file like "C:/Test/abc.txt" or a wrong folder path like "C:/Test" (without the last slash) will not have this effect and won't cause the runtime error.
I have only tested this on one system on a network drive under windows 10 with Microsoft Professional Plus 2019. It's entirely possible that it's an issue with the file system. Does anyone have any suggestions as to why is this happening? I now included the workaround to check if I'm passing a folder, but it's still unnerving.
The Documents.Open method opens the specified document and adds it to the Documents collection. It is designed to take the file path, not a folder. If you want to allow users to pick file(s) you may consider using the file open dialog. The FileOpenDialog triggered by your code which opens a folder for picking files allows specifying file formats that should be supported and visible via the dialog window.
Set dlgSaveAs = Application.FileDialog(msoFileDialogFilePicker)
dlgSaveAs.Filter = "Text Files (.txt)|*.txt|Word Documents (.docx)|*.docx|Word Template (.dotx)|*.dotx|All Files (*.*)|*.*"
dlgSaveAs.ValidateNames = true
Res = dlgSaveAs.Show

Macro broke after re-boot - Excel unable to locate external text files

As part of a larger macro Excel retrieves .dat files from a folder. After a crash and rebooting, the macro no longer works and seizes up upon trying to refresh.
There was also changes in security upon reboot where I had to enable all macros to be able to step though this current one.
I have double checked to make sure the path is correct and the files are still there.
Updated code and ended up crashing for unrelated memory issue. Fixed the memory problem and now won't run and is giving the same error code and message as before even with updated code. Current code which will run through the first loop but fails on the second.
If I am not mistaken, Dir just returns the filename found within that directory and not the full path to that file. What likely happened is your directory was initially set to F: so the macro used this as the default path when searching for the file. The best way to do this would be to store your directory in a constant string, and then append the two together. Something like this:
Const fPath as String = "F:YourPathHere\"
strFile = fPath & Dir(fPath & "*.dat")
Debug.Print strFile ' Just to make sure it is setting properly.

Would like to run an Excel macro with drag and drop

I have a macro that asks the user to choose an excel file and then outputs two text files based on the data.
I am looking for a way to just drop the excel file onto the macro file and have it process without the need for opening the macro file, a command button, an open file dialog, etc. I would like to drop the file on the other file and just have the two text files output.
I saw something that looked promising using a VBS file, but was unable to get it to work.
Here's the bare bones of what you need to do:
Wscript.echo "Begin..." 'just letting you know it's working
Set objArgs = Wscript.Arguments 'capture arguments; arg 0 is the name of the dropped file
Wscript.echo "The file name you dropped is:" & objArgs(0)
'DO STUFF TO THE FILE HERE
Wscript.echo "...Finished" 'all done
Save this to a file with a "vbs" extension.
Drag and drop a file onto it.
If your Windows file associations are properly setup,
you'll see this output a message for each of the wscript.echo
lines.

Overwrite an excel workbook when it is opened -VBA code

Is there any way to overwrite an excel file when it is opened using vba code?
I think you can't overwrite a file that is open. This is a windows limitation and as far as I know it is not possible to do it.
So I guess you'll have to save it with a different name.
EDIT: unless you are the person that has the file open.
If you open the file via VBA code, just workbookname.save should work
You can overwrite a file that is open in read only mode. To achieve this you need to set the file's attributes to be read only (thus forcing everyone, who's opening it to have it open in read only mode).
This can be done either within the Windows OS (change the file's properties), or through VBA using the SetAttr function https://www.techonthenet.com/excel/formulas/setattr.php
From my own experimentation I reached the following code, which you can use as an example. Assuming you're attempting to save a copy of the currently open workbook to strFileLocation, which is a string variable holding the output file's path, where the file may or may not already exist:
' Verify that the file exists.
If Dir(strFileLocation) <> vbNullString Then
' For some reason the read only flag needs to be removed for VBA to be able to overwrite the file.
SetAttr strFileLocation, vbNormal
End If
' Do the actual (over)writing
ThisWorkbook.SaveCopyAs strFileLocation
' Set the read only flag once more
SetAttr strFileLocation, vbReadOnly
```

Can't Delete INI File After Calling GetPrivateProfileString

I am having trouble deleting files after calling the GetPrivateProfileString command. I have the following code:
'Read the INI File
sb = New StringBuilder(500)
Select Case FileType
Case "Scanner File"
res = GetPrivateProfileString("ScannerSetings", "ScannerType", "", sb, sb.Capacity, Filename)
Case "Scale File"
res = GetPrivateProfileString("ScaleSetings", "ScaleType", "", sb, sb.Capacity, Filename)
End Select
'If the result is a value store it, otherwise move it to unprocessed
If res <> 0 Then InputArray.Add(sb.ToString)
File.Delete(Filename)
After reading the details from the INI file, as soon as I try to delete the file, I am getting the following error: The process cannot access the file 'R:\Drop\011_11_Scanner' because it is being used by another process.
I cannot even delete these files manually until I exit my application.
Any help would be appreciated.
Thanks
I cannot even delete these files manually until I exit my application.
This clearly shows that the file that Filename points to is locked. As long as it's locked, you won't be able to delete it.
Check your code for any file handles you have opened (eg for writing purposes) and did not close.
If you don't close a file after you've opened it, the file is not released and remains in locked state… which practically means it can not be deleted until (a) you close that file-handle, or (b) you close your program, since that's what's holding the file-handle after opening.
EDIT
The next thing that comes to mind is that VB.NET may need special user access rights to remove the INI on recent Windows versions. You can quickly cross-check that by simply executing your application with elevated user rights (eg via right-click menu; run as admin). I can't imagine that that's actually the problem — but it's worth a shot. Should it indeed be the problem, check (and modify) the permissions on the folder your application and/or INI resides in.