File System Object
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
-Brian
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
Thanks for the input Tim.
-Brian
ASKER
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
-Brian
ASKER
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
-Brian
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.
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.
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.
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.
ASKER
I will leave this open for a little bit longer to get some more input then Ill close it up.
-Brian
-Brian
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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"
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.
Ok....so how about setting the file to Hidden or Read only?
SetAttr "C:\path\file.txt", vbReadOnly
SetAttr "C:\path\otherfile.txt", vbHidden
SetAttr "C:\path\otherfile.txt", vbHidden
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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 :)