Invisible File Delete...

[JaedenRuiner]

Well,

I can do it in other languages but I can't seem to find the right one in VB.

FileIO.FileSystem.DeleteFile()

works, but i have to go file by file (enumerating through all the files in the directory) and it asks me if I should delete at each file.

Basically:

1. I create the Folder
2. I Create all the Files in the folder
3. I Use the files (email attachments)
4. Delete(MyFolder &"\*.*") With YES TO ALL

How would I do Step 4 so the user doesn't see Anything, just all the files I just created are now erased.

Thanks

 

[JohnH]

IO.Directory.Delete Method (String, Boolean) should do it.

 

[Tom]

The second parameter in FileSystem.DeleteFile; set this to FileIO.UIOption.OnlyErrorDialogs

        Dim strDirectory As String = "YourDirectoryPath"

        For Each foundFile As String In My.Computer.FileSystem.GetFiles(strDirectory, _
                                            FileIO.SearchOption.SearchAllSubDirectories, "*.*")

            My.Computer.FileSystem.DeleteFile(foundFile, _
                [COLOR="Red"]FileIO.UIOption.OnlyErrorDialogs[/COLOR], _
                FileIO.RecycleOption.DeletePermanently)
        Next

Edit: Sorry JohnH, saw your reply after I posted mine

 

[JaedenRuiner]

IO.Directory.Delete Method (String, Boolean) should do it.

That works wonderfully. Though, not precisely on topic, but related due to the nature of the original question:
Basically, I'm generating Word Documents (sometimes zipping multiple documents with Shell32) to become email Attachments. I have not yet tried this delete process while also using Mail.SendAsync(), and yet even so, occasionally I'm getting an error (exception) that one of the files is still in use. Now Technically (at the place in the code where the delete is executed) the file should have already been closed, but I understand the nature of file interaction can be...different, and such things are prone to occur, especially when I later add in the mail sending code (i'm not doing it now because the program isn't live yet, and I don't want an mailbox full of emails).

So, enough with my rambling, I'm wondering if there is a way that I can determine that there are no more "active" file handles to the files i'm about ready to purge. Both times when the exception was triggered, I checked with Unlocker program, and my application was the only app holding a handle to the file. It shouldn't have been, but...well, there it is. Can I ask if a handle is still open or something that would prevent a file from being deleted?
Thanks

 

[JohnH]

A doc file open? Could the Word app automation library still hold the reference even if document is closed? Tried closing the Word app for measure?

 

[JaedenRuiner]

Oh yea. I've read up on the Marshalling Issues with Word COM Objects, etc. My class intrinsically does that. Basically this is what happens:

I'm cycling through a Table based upon two IDs, CustID, BOL_ID. For Each CustID, I process Each BOL_ID, then Update each BOL Entry with the EmailID. When the Sum of BOL Quantities for said EmailID reaches 350, I Generate the Next EmailID (adding to the email table) and then continue until I'm done with all the BOL_ID's for that CustID. At that Point, I Generate My Email, using an embedded XML doc as the Email Structures, inserting COntact Name, Email Address, and the list of BOL_IDs for that Email. I then Open a Readonly Word Document that is blank and insert the Addresses (To/From) in the Appropriate Table Fields, and the EmailID which becomes their return BOL_ID. I SaveAs the Document, and then close out my Word Class. each step in the word class basically, Creates the Object (Application, Document), and I don't just set to nothing i Call Release() which is:

      Protected Friend Overridable Sub Release(ByRef o As Object)
         Try
            System.Runtime.InteropServices.Marshal.ReleaseComObject(o)
         Catch
         Finally
            o = Nothing
         End Try
      End Sub

CloseDocument calls Release on the _DOC variable, CloseApp() calls relase on the App variable, and if _doc is not nothing, CloseApp calls CloseDocument first just in case. And Close() calls CloseApp(), and Finalize() calls Close(), so in my app, i'm doing

try
WordClass.Open(filename)
 ' manipulation code of the document to add data
WordClass.Save(newFilename)
WordClass.Close
finally
WordClass = Nothing
end try

So the Word Com Object should not be holding the file open. The glitch has only happened twice and hasn't happened since, but the fact it "could" happen is why I want to protect against it. As well I am Also Doing This if there are more than one Word Document to be added as Attachments to the email:

      Private Function ZipBOLDocs(ByVal fSrc As Shell32.Folder, ByVal CustID As String) As String
         Dim fZip As Shell32.Folder = Nothing
         Dim fitm As Shell32.FolderItems3 = fSrc.Items
         Dim res As String = fSrc.ParentFolder.ParseName(fSrc.Title).Path & "\BOL_" & CustID & ".zip"
         fitm.Filter(64, "BOL_" & Right(CustID, 3) & "*.doc")
         If CreateZipFile(fZip, res) Then 
            fZip.MoveHere(fitm, 272) 
            Threading.Thread.Sleep(1000) 
            Return res
         End If
         Return String.Empty
      End Function

'And Just In case You wondered this is CreateZipFile:
   Public Function CreateZipFile(ByRef fZip As Shell32.Folder, ByVal sZipFile As String) As Boolean
      Dim s As New Shell32.ShellClass
      Dim f As New FileStream(sZipFile, FileMode.Create) 'ZipFile FileStream for BinaryWriter
      Dim bHead() As Byte = New Byte(23) {80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, _
                                                          0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} 

      Using w As New BinaryWriter(f) 
         w.Write(bHead, 0, bHead.Length) 
         w.Flush() 'Flushes the stream to disk
      End Using
      f.Close() 'closes the stream.
      If File.Exists(sZipFile) Then fZip = s.NameSpace(sZipFile) 
      Return CBool(fZip IsNot Nothing) 
   End Function

So that too could be adding a delay.

Thanks

 

[vis781]

When releasing COM objects sometimes there is a lag until the GC comes along. After calling release on the COM object start a Gargbage Collection.

GC.Collect

Think that should sort your problem