File System Object

BrianGEFF719
BrianGEFF719 used Ask the Experts™
on
Hello, First of all this isnt really a question, I just more would like to get some input on something. Latley I have seen a lot of programmers going with the FSO instead of native file commands in VB like (open, mkdir, rmdir, kill)...etc they are replacing all those commands with FSO. Here is the issue, I've run into problems where Norton AntiVirus, doesnt allow the FSO to be created. So if your program goes to a user with norton, its going to cause problems. Any input. BTW, I've personnally have had that problem with norton, I had to disable the Script Blocking. When I try to create a FSO Object, in ASP VBScript or Even VB, it will cause problems. Points will be spilt across all input.


-Brian
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2006

Commented:
that is a good question, Norton itself is saying to turn it off [temporarily of course]

title : What to do when creating scripts and Norton AntiVirus Script Blocking is enabled
source : http://service4.symantec.com/SUPPORT/nav.nsf/aab56492973adccd8825694500552355/fa999a879aac3b2f88256b450071c66e?OpenDocument

description
---------
Situation:
Norton AntiVirus (NAV) is installed and Script Blocking is enabled. You are creating or editing a Visual Basic or Java script, and you want to know whether any additional configuration of Script Blocking is required.

Solution:
We recommend that you temporarily disable the Script Blocking feature of NAV when creating or editing Visual Basic or Java scripts. If you do not, then Script Blocking may alert on the script during the creation or editing process.
---------

not a solution only the official stance :)
Head of Software Services
Commented:
Hi BrianGEFF719,

As a strong advocate against the FSO (long live PAFSO), I have never encountered this particular issue but it is an extra weapon in my armoury against that damn object! Every time I see a thread here recommending the FSO even if the code is good I always make an attempt to convert the questioner to the idea of either using native file functions or for some tasks API. As far as I am concerned there is nothing the FSO can do for you that cannot be done using native functions or api. Often faster than the FSO as well. I know this may sound like a simple reaffirmation of a negative view of the FSO and maybe it is. As far as I am concerned it has a place and that is in VBScript where you have no alternative.

Tim Cottee MCSD, MCDBA, CPIM
Brainbench MVP for Visual Basic
http://www.brainbench.com

Experts-Exchange Advisory Board Member

Author

Commented:
Tim: I tottaly agree with you. I dont understand why people would basically use an External Control to acomplish the same task. Ask your self this time, Would you use an External DLL to trim spaces from a string? or would you use the Trim() command, both would technically acomplish the same task, but the native function makes more sense. I just want someone's input who is for the FSO, I want someone to explain to me why FSO is better than native commands, i've asked this question before to people and they say "FSO looks cleaner". I dont think I will find a resonable explaination for FSO over Native Commands.

Thanks for the input Tim.


-Brian
Become a Microsoft Certified Solutions Expert

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Author

Commented:
I think the CreateObject() should be limited to VBScript & JScript, I dont even see a point for using CreateObject in VB. If you need to use CreateObject() you can just load the refrence to your VB Project, and you will even get a list of procedures.


-Brian

Author

Commented:
Microsoft is turning everything to **** by the way, In their quest to make everything work with everything, i think they are going to destroy the feakin' world.


-Brian

Commented:
Simple reason, why few people prefer FSO and others the native functions ,

those who started programming in the last 3/4 years( may be started with VB5/6) they prefer FSO. what they say is they are Object Oriented Programmers:)

those who started earlier than vb5 they prefer native functions and APIs or shell operations.

for voting purpose i prefer native functions and API.
TimCotteeHead of Software Services

Commented:
Brian:

I can just about take the argument that FSO makes things look cleaner at least to the uninitiated, anyone with any sense would simply create a class which wraps the api functions and have done with it. That overall is just as clean if not cleaner!

As for CreateObject, there are certain situations where the use of it is valid in VB. One instance is Lotus Notes 4.x automation, you cannot add the reference and work with the objects early bound (for some reason known only to Lotus/IBM perhaps) but have to use CreateObject and work late bound. There are some other similar instances where early bound references do not work as expected. Probably this is down to poor coding originally but we are no doubt all guilty of that from time to time.

I have to agree that you will probably not find a reasonable explanation for the use of FSO that actually stands up to scrutiny. In many ways I see it as a refuge for a lazy developer who is not willing to make the effort to investigate all possibilities and chooses to work with whatever seems to do the job there and then. In some cases this is a valid way of working, noddy utility applications rarely do things efficiently or elegantly but often do exactly the job they are expected to do. Using a tool such as VB is a double-edged sword, its low learning curve and relative ease of development mean that people can easily start developing applications, however because of this simplicity there is no need for people to develop the other necessary skills of evaluating options and analysing their code and working practices at the same time. This means we end up with lazy coding and people taking the "easy" way out all the time. If there are 3 ways to do something and one of them reads like english instead of gobbledygook then you should learn gobbledygook to understand whether it is the better method or not rather than taking the easy route.

Author

Commented:
I will leave this open for a little bit longer to get some more input then Ill close it up.


-Brian
As a member of PAFSO, you know my position.  I agree that the only reason someone would use it is because its "easier".

As far as CreateObject, another good use for it in VB is when you are working with interfaces and you want to load a particular component that implements a particular interface dynamically.  If you have many components using a particular interface, it would not make sense to have to reference every single one of them, or reference a new one every time a new component that implemented that interface was created.  All you reference is the interface class, and use that throughout your project.

Commented:

Maybe I have just been using FSO forever, but how would you all, lets say, "move" a file from one directory to another in VB without FSO (or API's since they are not native either)?

Name "C:\path\file.txt" As "C:\newpath\file.txt"

Commented:

I've also noticed that the Append NTFS permission is apparently not suppored by either FSO or the built in VB file functions (or C/C++ etc).  The Append directive is supported, but that doesn't work with the Append NTFS permission (its essentially a write to the end of the file rather then a true Append).  I haven't checked whether it is supported by .NET yet, but odds are it isn't.  So, whichever method accomodates the NTFS Append permission properly in the future will probably be the one that I will use.  Odds they will fix that in the FSO object first (and in .NET), before they toy around with VB6 or earlier.

Commented:

Ok....so how about setting the file to Hidden or Read only?
SetAttr "C:\path\file.txt", vbReadOnly
SetAttr "C:\path\otherfile.txt", vbHidden
Commented:

Then that pretty much covers all the methods.  I was actually just curious because I've never really used the built in for anything other then openning files.  All my file maintanance functions I've always written in FSO and its a pain to search Microsoft to find the built in method since the help always gives you the FSO method for most everything.  Call me lazy, but I just wanted you to tell me the command names...hee hee.  Still, that is one reason to use the FSO.  Everything is in the object and you don't have to remember the name of different commands.  Just remember FSO and everything else you can easilly find out by checking the object methods.  Using the built in VB commands makes you remeber each commend uniquely (though I think I'm being far to lazy again, because thats not such a big deal).

I suppose the best choice for development would be whichever method Microsoft will be supporting for future releases of VB and for maintainance of older versions of VB.  Like for insance, if Microsoft adds additional functionality to the FSO like support for the NTFS permissions (enumration of users that have access to a file, or who is the owner of the file etc...) then that would add functionality that isn't directly available through VB (without API function calls and a mess of support code).  It seems to me that whenever you try to get help from Microsoft on file manipulation they give you the FSO approuch over the built in.  Maybe that means that they give the FSO priority for future functionality related to the file system.  Who can know?

I guess the short answer is that you should use the built in functions, if you can remember the command names, and if they do what you want them to do (just like you are saying).  However, you should keep an eye on what additional functionality might be added to FSO for future releases.  And with my new found knowledge (thanks to AzraSound) of the built in command names, I guess I'll do the same (at least until I forget that SetAttr is the command name to change the file attributes, etc).

Commented:
I still support File System Object for various reasons. Ironically i come from a computing background and have worked with loads and load of API. I would defenitely say that API would beat FSO hands down.

Tim, I'd totally agree to your comments the other day where u told me that it was like putting a Ferrari Chassis over a Mini Cooper. Yet, I would still support File System Object. My job involves working with VB/ASP/SQL Server and at times Excel Macros. There are so many requirements and so many of them to do with file operations. I don't have the time or patience to sit and write seperate codes and modules all the time for various things. Instead i've a common code which has most of the functions of FSO in it. All i do is, copy and paste across my ASP Pages, Excel Macros or into my VB Code.

1. Its easy to use.
2. Works in Excel Macros.
3. Works in ASP.
4. I needn't need to remember any syntax.
5. I needn't need to remember any API Calls.
6. Lesser Coding.
7. Graceful Coding and very much legible (if coded properly)

All i do is Set objFileSystemObject = New FileSystemObject and the rest is all upto VB's Intellisense to show me what the object has and what it doesn't!!! Doesn't this make life so much more simpler? I wouldn't bother saving some milliseconds over effieciency.

I realized that most of you who have given your inputs on this question are featured in the top 15 Visual Basic experts of 2003 and the others are way up the ladder. However, this won't fend me off and i would continue using FSO and provide solutions for people with FSO. It makes their lives also simpler rather than them having to understand all about APIs.
srimanth,
We are not suggesting using the API, but the built-in VB native file I/O and related functions.  I shy away from any API myself with regards to file operations, unless I see a real benefit in doing so.  You have just as many, or fewer, functions to remember using native VB, but you "think" its easier to remember because, as mentioned before, you can reference FSO and get the intellisense capabilities.  Well, if thats all that is holding you back, try doing a "VBA.FileSystem." in your projects.  Maybe we can convert you guys after all.   :-)

Also, like we said, there are times when FSO is not only preferred, but the standard, such as in VBScript (e.g., your ASP pages).  You don't have access to the native VB functions from ASP, so FSO is your immediate alternative, and that was the original reason it was created by Microsoft, hence the name, File *SCRIPTING* Object.

Lesser Coding?  I have shown above several one line calls from VB, as opposed to the variable declaration, object instantiation, and finally the method call using FSO.

That leaves us with points 1 and 7 you noted.  I agree, its easy to use, which means MS did it right (for once).  Also, it can read better.  So, if aesthetics is important to you, sure, FSO is fine.
Commented:
Conversion??? Hmmm.... sounds like a religion conversion to me ;)....

I really appreciate all your (Brian's, Tim's & Azra's) inputs in making coding more techincal and more efficient and to deliver better solutions.

But win32 is a serious MESS and i mean it from the core of my heart. I used to always use Win32 API for all of my projects for all of the file operations and insist that my team also use the same. Code maintenance became a nightmare as the team was changing dynamically. Most of my team members didn't know anything about API, but knew about FSO. It makes my life all that simpler and easier to manage everything.

As a simple example, refer to the question:
http://www.experts-exchange.com/Programming/Programming_Languages/Visual_Basic/Q_20717290.html

Vinny's solution is probably the ideal solution to use. But imagine something going wrong or if the user wants to modify something a little bit. He starts searching for some help on SHFILEOPSTRUCT and what does he get???

typedef struct _SHFILEOPSTRUCT{
    HWND         hwnd;
    UINT         wFunc;
    LPCSTR       pFrom;
    LPCSTR       pTo;
    FILEOP_FLAGS fFlags;
    BOOL         fAnyOperationsAborted;
    LPVOID       hNameMappings;
    LPCSTR       lpszProgressTitle;
} SHFILEOPSTRUCT, FAR *LPSHFILEOPSTRUCT;

This would obviously scare him off. What would the above mean to him? How would anyone not so experienced with win32 API even know that a Windows Handle is represented as Long in VB?

These are people who don't know solutions. That's the reason why they come to such forums in need of some help. We may be a bunch of people who know better than the others, but then they have come to us for a solution and we do not scare them with some greek and latin code. Many people have intutedly started using VB due to its ease of programming and developing rapid solutions. They would be the happiest people with solutions with FSO as Intellisense would always assist them with the various other features which will enable them to play around.

Anyways, its time for me to bid adios!!! I don't know which part of the globe u all are, but i am in London and its evening time and on a Friday means Beer Time!!! Have a great Weekend and will follow up with this on Monday.

cheers,
srimanth.
TimCotteeHead of Software Services

Commented:
srimanth, hope you had a good beer (or two or three). I am actually just down the M3 in Southampton and also had an appointment with a beer on Friday evening.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial