Dim sw As StreamWriter
        Try
            sw = File.AppendText(CurDir() & "\deskimages.txt")
            sw.Write(TextBox1.Text & " " & TextBox2.Text)
            sw.Flush()
        Catch exc As Exception
            MsgBox(exc.Message)
        Finally
            If Not sw Is Nothing Then
                sw.Close()
            End If
        End Try
        Dim tw As IO.TextWriter
        tw = System.IO.File.CreateText(CurDir() & "\profiles2\" & TextBox1.Text & " " & TextBox2.Text & ".txt")
        tw.WriteLine(TextBox1.Text)
        tw.WriteLine(TextBox2.Text)
        tw.WriteLine(TextBox3.Text)
        tw.WriteLine(ComboBox1.SelectedItem)
        tw.WriteLine(ComboBox2.SelectedItem)
        tw.WriteLine(TextBox4.Text)
        tw.Dispose()
        tw.Close()
        Me.Close()

I don't get what isn't working...it's supposed to add a line to the deskimages.txt and then after wards, create another text file somewhere else and write data to it. But it says the deskimages.text is in use. Any help?

Dani AI

Generated

After confirmed the immediate problem was resolved, the following notes collect practical patterns and quick troubleshooting steps that reduce the chance of running into "file in use" errors and make them easier to track down later.

Prefer deterministic disposal: wrap readers/writers in a Using block so the runtime always closes the handle even on exceptions (). For simple appends, a single-call helper avoids manual stream management:

IO.File.AppendAllText(path, text & Environment.NewLine)

When concurrent access is required, be explicit about sharing and locking. A FileStream constructor lets you set FileShare so readers can coexist with writers; use this only when the semantics are safe for your scenario (FileShare enum). Within a single process, synchronize access with a dedicated helper or SyncLock; across processes, consider a named Mutex instead of relying on file-sharing quirks.

If the problem reappears, use a handle/lock tracer to find which process or thread holds the file: Sysinternals Process Explorer or Handle are reliable for this (Process Explorer download: https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer). Also catch and log IOException stack traces and optionally implement a short retry-with-backoff when transient locks appear. As noted, marking threads resolved helps future visitors find the fix; keeping a short comment in code explaining why a specific sharing or locking choice was made also prevents regressions.

Recommended Answers

All 2 Replies

Wow I'm an idiot. It was reading it but not closing on another form. Thanks anyways!

If you have got the sollution then plz mark the thread as solved.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.