Add-in created folder can't be deleted

[MAB]

An add-in created folder (MkDir) cannot be deleted unless the application
utilizing the add-in is closed.

Any thoughts?

[Karl E. Peterson]

Post by MAB
An add-in created folder (MkDir) cannot be deleted unless the
application utilizing the add-in is closed.
Any thoughts?

My first thought is that perhaps you need to improve your diagnostic skills.

[MAB]

Thanks for the unconstructive criticism.

Why the rudeness? Not all of us are experts (hence the reason for
Newsgroups).

Post by Karl E. Peterson

Post by MAB
An add-in created folder (MkDir) cannot be deleted unless the
application utilizing the add-in is closed.
Any thoughts?

My first thought is that perhaps you need to improve your diagnostic skills.
--
Working without a .NET?
http://classicvb.org/

[Bob Butler]

Post by MAB
An add-in created folder (MkDir) cannot be deleted unless the
application utilizing the add-in is closed.
Any thoughts?

Sounds like the add-in, or the application using it, has the folder open.
If, for example, the add-in uses Dir$ to check the folder it could easily
have it open. In that case using Dir$("nul") should release it. If the
application has been used to browse to the folder then you may need to
browse to another folder. Since you didn't specify the application or
anything about the sequence of events to allow anybody to try to replicate
the probelm it's all just conjecture though. I suspect that's what Karl was
alluding to even if he might have been a tad more diplomatic <g>.

[MAB]

Thanks for the help Bob.

There are 7 places in the code where I use DIR to check for the existance of
a folder. I tried your dir$("nul") in all 7 places but it didn't help to
release the folder.

Below is one of the 7 location were I use DIR. I tried dir$("nul") as a
function [gS = Dir$("null")] and as a Sub [dir$ "nul"] but neither worked.

sLastCopyFolder = GetSetting("BBH", "DrawingAccess",
"LastCopyFolder", _
"C:\Documents and Settings\" & Environ("username") & "\My
Documents")
If Dir(sLastCopyFolder, vbDirectory) = "" Then
sFile = sNewestFileInFolder("C:\Documents and Settings\" &
Environ("username") & _
"\My Documents", "*.skv")
Else
gS = Dir$("null")
sFile = sNewestFileInFolder(sLastCopyFolder, "*.skv")
End If

Post by Bob Butler

Post by MAB
An add-in created folder (MkDir) cannot be deleted unless the
application utilizing the add-in is closed.
Any thoughts?

Sounds like the add-in, or the application using it, has the folder open.
If, for example, the add-in uses Dir$ to check the folder it could easily
have it open. In that case using Dir$("nul") should release it. If the
application has been used to browse to the folder then you may need to
browse to another folder. Since you didn't specify the application or
anything about the sequence of events to allow anybody to try to replicate
the probelm it's all just conjecture though. I suspect that's what Karl was
alluding to even if he might have been a tad more diplomatic <g>.
--
Reply to the group so all can participate
VB.Net: "Fool me once..."

[Bob Butler]

Post by MAB
Thanks for the help Bob.
There are 7 places in the code where I use DIR to check for the
existance of a folder.

Don't use Dir for existence testing; use something like GetAttr

Public Function Exists(ByVal ThePath As String) As Boolean
Dim x As Long
On Error Resume Next
x = GetAttr(ThePath)
Exists = (Err.Number = 0)
Err.Clear
End Function

You can extend it to restore prior error values and/or distinguish files
from folders as needed

[MAB]

Right on target. After replacing all calls to DIR (for folder and file
existence) with you routine, I can now delete the folders my app creates
without having close the app first.

It never dawned on me that DIR could have been the problem. Why would an on
the fly query (folder/file existence) like this hold on to a file? The MSDN
document doesn't mention it.

Thanks again for the assist Bob!

Post by Bob Butler

Post by MAB
Thanks for the help Bob.
There are 7 places in the code where I use DIR to check for the
existance of a folder.

Don't use Dir for existence testing; use something like GetAttr
Public Function Exists(ByVal ThePath As String) As Boolean
Dim x As Long
On Error Resume Next
x = GetAttr(ThePath)
Exists = (Err.Number = 0)
Err.Clear
End Function
You can extend it to restore prior error values and/or distinguish files
from folders as needed
--
Reply to the group so all can participate
VB.Net: "Fool me once..."

[Karl E. Peterson]

Post by MAB
It never dawned on me that DIR could have been the problem. Why
would an on the fly query (folder/file existence) like this hold on
to a file? The MSDN document doesn't mention it.

Dir operates by opening a file search handle with FindFirstFile, and leaving
this handle open for subsequent FindNextFile calls. There is no VB
mechanism to force the needed FindClose call. That's just another reason
Dir is ill-advised for simple "exists" tests. The correct use of Dir is
*far* more complicated than the docs might indicate.

[MAB]

Now that was constructive. In the future I'll offer up more inform up front.

Thanks Karl, Bob & Ralph.

Post by Karl E. Peterson

Post by MAB
It never dawned on me that DIR could have been the problem. Why
would an on the fly query (folder/file existence) like this hold on
to a file? The MSDN document doesn't mention it.

Dir operates by opening a file search handle with FindFirstFile, and leaving
this handle open for subsequent FindNextFile calls. There is no VB
mechanism to force the needed FindClose call. That's just another reason
Dir is ill-advised for simple "exists" tests. The correct use of Dir is
*far* more complicated than the docs might indicate.
--
Working without a .NET?
http://classicvb.org/

[Karl E. Peterson]

Since you didn't specify the application or anything about the
sequence of events to allow anybody to try to replicate the probelm
it's all just conjecture though. I suspect that's what Karl was
alluding to

Bingeaux.

even if he might have been a tad more diplomatic <g>.

You think? I thought I offered more information than he did. <g>

[Ralph]

Post by MAB
An add-in created folder (MkDir) cannot be deleted unless the application
utilizing the add-in is closed.
Any thoughts?

You usually can't delete a folder if the folder is still being used by
another process.
[
Simple example:
Open a DosPrompt Window, create a directory type 'md junky'
Keep this window open, and open another DosPrompt Window.
In the second DosPrompt type 'cd junky'.
Tab back to the first DosPrompt and type 'rd junky'.
You will get an error.
Close the second DosPrompt window.
Run 'rd junky' again in the first window, and the folder is removed.
]

You need to find out who or what is 'using' that folder. Perhaps a simple
ChDir() away from the folder will 'fix' the problem.

-ralph