API vs. FSO

Would some of you please explain why you prefer the Windows API
drives/directories/files functions to the FSO and its associated objects?
Other than performance, why choose one over the other?

Personally, I prefer the API calls because somewhere in my mind, I believe
that they are more robust.  I don't actually know if this is true.  Is it?

I've also noticed that some are rabidly contre the Scripting Objects (FSO
and Dictionary).  Again, would you please explain why?

TIA,
--
Joe

VBA Automation/VB/C++/Web and DB development

Joe wrote:

> Would some of you please explain why you prefer the Windows API
> drives/directories/files functions to the FSO and its associated objects?
> Other than performance, why choose one over the other?

The only benefit the FSO has is a decent object model. Other than that,
there's zero reason to use it. VB's runtime has everything you need to
access files of any type built right in (not true with FSO).

> Personally, I prefer the API calls because somewhere in my mind, I believe
> that they are more robust.  I don't actually know if this is true.  Is it?

FSO's slow....

Performance Comparison - FSO vs. API
http://vbnet.mvps.org/index.html?co...oapicompare.htm

> I've also noticed that some are rabidly contre the Scripting Objects (FSO
> and Dictionary).  Again, would you please explain why?

If, by contre, you mean dislike, there are several reasons. First, it's
scripting (=slow), second, using the API or VB's built in file support,
there's no need to distribute an additional library... third.. that
library stands a good chance of breaking someone elses PC... fourth,
some virus scanners hate scripting of any kind.

> TIA,

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

Ken,  Thanks for your reply.  Please see below.

"Ken Halter" wrote:
>
>
> Joe wrote:
> 
>
> The only benefit the FSO has is a decent object model. Other than that,
> there's zero reason to use it. VB's runtime has everything you need to
> access files of any type built right in (not true with FSO).

By VB's runtime, do you mean the API functions or functions like Dir, etc?
I don't know enough about VB's runtime to understand this statement.

> 
>
> FSO's slow....
>
> Performance Comparison - FSO vs. API
> http://vbnet.mvps.org/index.html?co...oapicompare.htm
> 
>
> If, by contre, you mean dislike, there are several reasons. First, it's
> scripting (=slow), second, using the API or VB's built in file support,
> there's no need to distribute an additional library... third.. that
> library stands a good chance of breaking someone elses PC... fourth,
> some virus scanners hate scripting of any kind.

Scripting, as opposed to compiled?  What engibe executes the scripted code
for the FSOs?

VB's built in file support?  Does this include Dir, ChDir, etc?

How does the library stand a good chance of breaking someone elses PC?

Thanks, Ken.

> 
>
> --
> Ken Halter - MS-MVP-VB - http://www.vbsight.com
> Please keep all discussions in the groups..
>

Joe wrote:
> By VB's runtime, do you mean the API functions or functions like Dir, etc?
> I don't know enough about VB's runtime to understand this statement.

Dir's a fairly crude example since it's pretty limited <g>... I was
referring to the basic Open/Close functionality that allows you to
read/write to any type of file (binary too)... FSO has no support for
Binary file i/o.

Basically, VB's built in methods can do anything the FSO can do... only
faster. The only benefit to the FSO is the object model that makes it
appear to be "object oriented". It has a couple of bells and whistles
(due to the object model) but even that's replaceable with either
straight VB code or API calls..

If interested, this'll give you "the best of both worlds" with no scripting.

FileSystemLib
http://www.killervb.com/FileSystemLib.aspx

> Scripting, as opposed to compiled?  What engibe executes the scripted code
> for the FSOs?

Windows Scripting Host (afaik)

> VB's built in file support?  Does this include Dir, ChDir, etc?
>
> How does the library stand a good chance of breaking someone elses PC?

DLL Hell. Very few libraries are "self contained". Most need help from
other components in a system to work correctly. If you distribute the
wrong version of any windows components, you run the risk of rendering
the end users PC (temporarily) useless. FSO's not the only thing that
causes this... Riched32's a prime example.

Q197580 - INFO Distribution Issues with Riched32.dll
http://support.microsoft.com/suppor...s/Q197/5/80.ASP

and... this is what happens if you ignore the issues...

Q236286 - PRB Out of Memory Error Message Using the Rich Textbox Control
http://support.microsoft.com/suppor...s/Q236/2/86.ASP

Back to the FSO, this one's not so bad (but still)

Subject: Re: Type Mistmatch error after a year of running fine...
http://groups.google.com/groups?hl=...r />
gp05%26rn
um%3D1

Here are a few more...

Results 1 - 29 of about 56 English messages for "don't use the FSO"
group:*.vb.*. (5.72 seconds)
http://groups.google.com/groups?as_...scoring=d&hl=en

..many more where those came from <g>

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

"Joe" <Joe@discussions.microsoft.com> wrote in message news:898CDE91-
9B62-48C1-9800-D173A1C9F3C6@microsoft.com
> Would some of you please explain why you prefer the Windows API
> drives/directories/files functions to the FSO and its associated
> objects? Other than performance, why choose one over the other?
>
> Personally, I prefer the API calls because somewhere in my mind, I
> believe that they are more robust.  I don't actually know if this is
> true.  Is it?
>
> I've also noticed that some are rabidly contre the Scripting Objects
> (FSO and Dictionary).  Again, would you please explain why?

FSO is slow, adds overhead, requires and external DLL, and is sometimes
disabled by corporate policies to avoid virus issues.  If you don't
distribute the DLL you have to deal with incompatible versions that exist
"in the wild".  It also adds nothing that can't be done with native VB
syntax and/or some windows API work that is well documented and for which
numerous samples exist.

The dictionary does provide functionality that is harder to duplicate in VB
although there are samples around that accomplish it.  The main issue with
that IMO is that it requires the extra DLL and you run into the same issues
of the DLL being incompatible and/or unusable by policy.

Thank you.  This has been enormously helpful.

"Ken Halter" wrote:

> Joe wrote: 
>
> Dir's a fairly crude example since it's pretty limited <g>... I was
> referring to the basic Open/Close functionality that allows you to
> read/write to any type of file (binary too)... FSO has no support for
> Binary file i/o.
>
> Basically, VB's built in methods can do anything the FSO can do... only
> faster. The only benefit to the FSO is the object model that makes it
> appear to be "object oriented". It has a couple of bells and whistles
> (due to the object model) but even that's replaceable with either
> straight VB code or API calls..
>
> If interested, this'll give you "the best of both worlds" with no scriptin
g.
>
> FileSystemLib
> http://www.killervb.com/FileSystemLib.aspx
> 
>
> Windows Scripting Host (afaik)
> 
>
> DLL Hell. Very few libraries are "self contained". Most need help from
> other components in a system to work correctly. If you distribute the
> wrong version of any windows components, you run the risk of rendering
> the end users PC (temporarily) useless. FSO's not the only thing that
> causes this... Riched32's a prime example.
>
> Q197580 - INFO Distribution Issues with Riched32.dll
> http://support.microsoft.com/suppor...s/Q197/5/80.ASP
>
> and... this is what happens if you ignore the issues...
>
> Q236286 - PRB Out of Memory Error Message Using the Rich Textbox Control
> http://support.microsoft.com/suppor...s/Q236/2/86.ASP
>
> Back to the FSO, this one's not so bad (but still)
>
> Subject: Re: Type Mistmatch error after a year of running fine...
> http://groups.google.com/groups?hl=...0tkmsftngp05%26
rnum%3D1
>
> Here are a few more...
>
> Results 1 - 29 of about 56 English messages for "don't use the FSO"
> group:*.vb.*. (5.72 seconds)
> http://groups.google.com/groups?as_...scoring=d&hl=en
>
> ...many more where those came from <g>
>
> --
> Ken Halter - MS-MVP-VB - http://www.vbsight.com
> Please keep all discussions in the groups..
>

"Joe" <Joe@discussions.microsoft.com> wrote in message
news:898CDE91-9B62-48C1-9800-D173A1C9F3C6@microsoft.com...
> Would some of you please explain why you prefer the Windows API
> drives/directories/files functions to the FSO and its associated
objects?
> Other than performance, why choose one over the other?

Is there really anything else? <g>

Even if there were no other problems/issues, this would still be a
decisive factor.

Saga

>
> Personally, I prefer the API calls because somewhere in my mind, I
believe
> that they are more robust.  I don't actually know if this is true.  Is
it?
>
> I've also noticed that some are rabidly contre the Scripting Objects
(FSO
> and Dictionary).  Again, would you please explain why?
>
> TIA,
> --
> Joe
>
> VBA Automation/VB/C++/Web and DB development

Hi,
some FSO methods used not to close file handles, then you cannot delete a
file until you completely release the FSO instance.
This is equivalent of doing this using API:

Dim retdata As WIN32_FIND_DATA
Dim handle As Long
handle = FindFirstFile(MaskOrName, retdata)
If handle = INVALID_HANDLE_VALUE Then
FileExists = False
Else
FileExists = True
..
end if

while forgetting to do this:

handle = FindClose(handle)

Terrible.

regards,
Vlad
www.vbrocks.net



"Joe" <Joe@discussions.microsoft.com> wrote in message
news:898CDE91-9B62-48C1-9800-D173A1C9F3C6@microsoft.com...
> Would some of you please explain why you prefer the Windows API
> drives/directories/files functions to the FSO and its associated objects?
> Other than performance, why choose one over the other?
>
> Personally, I prefer the API calls because somewhere in my mind, I believe
> that they are more robust.  I don't actually know if this is true.  Is it?
>
> I've also noticed that some are rabidly contre the Scripting Objects (FSO
> and Dictionary).  Again, would you please explain why?
>
> TIA,
> --
> Joe
>
> VBA Automation/VB/C++/Web and DB development

"Joe" <Joe@discussions.microsoft.com> wrote in message
news:898CDE91-9B62-48C1-9800-D173A1C9F3C6@microsoft.com...
> Would some of you please explain why you prefer the Windows API
> drives/directories/files functions to the FSO and its associated objects?
> Other than performance, why choose one over the other?


Isn't that reason enough?

Mike