Prev: No license to use this functionality
Next: XML displays in console but not in text boxes
From: Billl on 3 Jul 2008 10:53
I'll be durned. Learn something every day I guess. I would have bet it
was just looking for a file named 'nul' with no extension.

Billl

--->
> The "nul" is the Windows "null device" (i.e. a special file name) and
> nothing to do with vbNullString Bill
>
> Karl, you may be thinking of my original post on this subject:
> http://groups.google.ie/group/microsoft.public.vb.general.discussion/msg/5e589d1e61920a5e?hl=en
>
> Tony Proctor
>
> "Billl" <whatever(a)whichever.com> wrote in message
> news:Oj5ROLL3IHA.3508(a)TK2MSFTNGP02.phx.gbl...
>> --->
>>> Hi Folks --
>>>
>>> I just wanted to be sure about something, so I wrote up a little test...
>>>
>>> Option Explicit
>>>
>>> Private Sub Command1_Click()
>>> Debug.Print Dir("c:\*.*")
>>> End Sub
>>>
>>> Private Sub Command2_Click()
>>> Debug.Print Dir("nul")
>>> End Sub
>>>
>>> Compiling that, and watching it in TaskMgr, I see the Handle count rise
>>> when I press Command1 and drop when I press Command2. I've tried
>>> googling for this, to no avail, but I know I've seen threads here before
>>> about releasing the search handle VB creates by calling FindFirstFile on
>>> a Dir.
>>>
>>> I did find posts suggesting that passing vbNullString would do it too,
>>> but that doesn't seem to be the case given the above test. Anyone have
>>> any thoughts on this?
>>>
>>> Thanks... Karl
>> Karl:
>>
>> I don't think that your "nul" is actually vbNullString. Isn't it simply a
>> three-character string of "n", "u", and "l"?
>>
>> Billl
>
>
From: expvb on 3 Jul 2008 11:40
I just tested various combinations using a compiled VB6+SP5 app on XP+SP2,
and the result is below. I did these one by one and recompiled each time:

These released the previous Dir handle. The first is a non existing file or
folder. None of these statements generated a run time error:

Debug.Print Dir("skldjfhlksdfhkasjdlfkaslkdjasjkdlaskdl")
Debug.Print Dir(";")
Debug.Print Dir(Chr(34))
Debug.Print Dir("<")
Debug.Print Dir(">")
Debug.Print Dir("nul")

These did not release the previous Dir handle. None of these statements
generated a run time error:

Debug.Print Dir("")
Debug.Print Dir("\")
Debug.Print Dir("C:\")
Debug.Print Dir(vbNullString)

The following generated a run time error 52: Bad file name or number.

Debug.Print Dir("|")



From: Tony Proctor on 3 Jul 2008 12:35
You cannot have a folder called nul Peter. nul is a special file name, just
like com1, etc

See http://msdn.microsoft.com/en-us/library/aa365247.aspx

Tony

"PeterD" <peter2(a)hipson.net> wrote in message
news:n5pp64l3ktrnob8nk20lbf6fcr7pqkdp50(a)4ax.com...
> On Wed, 2 Jul 2008 17:39:15 -0700, "Karl E. Peterson" <karl(a)mvps.org>
> wrote:
>
>>Hi Folks --
>>
>>I just wanted to be sure about something, so I wrote up a little test...
>>
>> Option Explicit
>>
>> Private Sub Command1_Click()
>> Debug.Print Dir("c:\*.*")
>> End Sub
>>
>> Private Sub Command2_Click()
>> Debug.Print Dir("nul")
>> End Sub
>>
>>Compiling that, and watching it in TaskMgr, I see the Handle count rise
>>when I press
>>Command1 and drop when I press Command2. I've tried googling for this, to
>>no avail,
>>but I know I've seen threads here before about releasing the search handle
>>VB
>>creates by calling FindFirstFile on a Dir.
>>
>>I did find posts suggesting that passing vbNullString would do it too, but
>>that
>>doesn't seem to be the case given the above test. Anyone have any
>>thoughts on this?
>>
>>Thanks... Karl
>
> In Dir("nul") you (probably) don't have a folder named "nul" so the
> dir command completes, and frees its handle? I think you will find the
> same is true when the Dir() is called (no parameter) sufficiently to
> enumerate all the items in the given folder based on the first call
> that creates the handle.


From: Karl E. Peterson on 3 Jul 2008 14:01
Billl wrote:
> I don't think that your "nul" is actually vbNullString.

Definitely not. It's a reserved device name, just like com1 or lpt2.
--
..NET: It's About Trust!
http://vfred.mvps.org


From: Karl E. Peterson on 3 Jul 2008 14:05
Tony Proctor wrote:
> Karl, you may be thinking of my original post on this subject:
> http://groups.google.ie/group/microsoft.public.vb.general.discussion/msg/5e589d1e61920a5e?hl=en

Yes! That's the post I was searching for.

My test (top post) seems to corroborate those results. What did you use to make
your determination?

What I also found interesting is the number of folks suggesting using nul to test
for directory existance, too. And, that not only does this seem to work, but it
also clears the cached search handle. Whether the directory exists or not!

One thing in your post I didn't test (yet)...

> There are quite a few posts acknowledging that Dir() has this unfortunate
> side-effect of locking the directory until the search has been exhausted Karl
> (i.e. blank has been returned). It's a real PIA if you want to prematurely
> terminate the search, based on some additional criteria.

That implies that if you loop through until Dir() returns just an empty string, that
VB does actually call FindClose at that point? Something I think I'll try to test
as well.

Thanks... Karl
--
..NET: It's About Trust!
http://vfred.mvps.org


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: No license to use this functionality
Next: XML displays in console but not in text boxes