Jürgen Welz
jwelz at hotmail.com
Wed May 5 17:21:53 CDT 2004
It's the script kiddy playground known as the scripting runtime library that I have commonly seen disabled. The FSO is simply one of the objects in that library and its loss is usually a byproduct of Admin wariness of the ease with which a novice can wreak havoc using the script capabilities. Dir supports use of the standard DOS wild cards. In your other post you mention the use of Kill. I place files in the recycle bin whenever possible because if a user deletes a file with an interface I've provided, I believe that he should at least get the protection that Windows itself affords. Of course if your code created a temporary file, there is no reason it shouldn't clean up after itself without using the recycle bin. Ciao Jürgen Welz Edmonton, Alberta jwelz at hotmail.com >From: DWUTKA at marlow.com > >If you really want one, let me know. I was working on a FSO like VBA class >set. I got tied up in a nifty 'ability', which would let you 'monitor' >files and folders, then I got tied up in other things, so that project >dropped to the side. > >There are drawbacks to FSO, but in some cases, it's all you can use. One >example of a drawback, you can't search with a wildcard (at least I didn't >see anything like that when I needed it). So you have to look through an >entire folder. Not a big deal, unless you are looking through 50,000 >files. >In ASP, you cannot use Dir, but you can use a VB .dll with Dir inside of >it. > >I have seen system Admins disable FSO, but I don't think it's as big of an >issue as some portray. (Dare I say this is sort of like the Lookup >property >of a field....LOL) > >Drew > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby >Sent: Tuesday, May 04, 2004 10:02 PM >To: Access Developers discussion and problem solving >Subject: RE: [AccessD] FS object > > >And I have never found the FSO disabled. Not that an idiot can't disable >it >(and they would be an idiot to do so), just that it has never been an issue >to me. > > >I ran a test comparing the API dir performance with VBA Dir and the VBA >was >faster. > >And I care because? And how much faster? Noticable to a human being? > >The api could retrieve file creation time and additional attributes but at >a >cost of performance. > >And I care because? And how much performance cost? Noticable to a human >being? > >You can create directories in less time than it takes to load the FSO. > >And I care because? How much less time? Noticable to a human being? > >As for developing my own FSO... we've been over this before. You (in the >past anyway) refused to use collections, insisting on rolling your own from >arrays. I love collections and would never dream of building my own. > >Sometimes you remind me of Steve Gibson. Still programming in assembler >because "that's all he needs". > >I have a job to do, and dimming a FSO and using it's properties is >infinitely faster than rolling my own FSO. The extra millisecond required >to get a pointer to the FSO is completely irrelevent, to me, to my >customers, to most of the world. > >Should the job call for a scalpel, then perhaps I would agree with you, but >the fact is it doesn't. > >The FSO is NOT a backhoe or a chainsaw, it is just a tool. It is a >reasonably well designed programming model to allow you to do everything >you >would ever need to do with the file system, complete with help files, >intellisense and the rest. > >I'll tell you what I will do though. If you ever contribute to the list >even one 10th the power of the FSO in a well designed class that I can drop >into my application and just use (as I can the FSO) then I will use your >class. Until such time... (and I'm not holding my breath waiting) uh.... >it >seems the FSO wins my business. > >John (the backhoe operator) Colby. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jürgen Welz >Sent: Tuesday, May 04, 2004 10:34 PM >To: accessd at databaseadvisors.com >Subject: RE: [AccessD] FS object > > >I find the scripting runtime is not enabled in many environments. Hence no >FSO. VB(A) is incredibly fast in working with the file system. File size, >date modified and file/folder names are immediately available from the Dir >function. I ran a test comparing the API dir performance with VBA Dir and >the VBA was faster. The api could retrieve file creation time and >additional attributes but at a cost of performance. You can create >directories in less time than it takes to load the FSO. > >I have never had to provide any file system functionality that wasn't >already built into VBA. When the job calls for a scalpel there is no need >to get out a chain saw or a back hoe. It's also like a comparison between >a >public shared plastic spoon vs your own private silverware. > >Ciao >Jürgen Welz >Edmonton, Alberta >jwelz at hotmail.com _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines