John W. Colby
jwcolby at colbyconsulting.com
Tue May 4 22:02:16 CDT 2004
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 >From: "John W. Colby" <jwcolby at colbyconsulting.com> > > >Have I said before I hate the FS object... > >No doubt. > >Not sure exactly why. It is just an object model that allows manipulation >of the file system. Why not hate DAO? Why not hate the Excel object >model? >Why not hate ... > >Never mind. > >It's just a tool. > >John W. Colby >www.ColbyConsulting.com _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=htt p://hotmail.com/enca&HL=Market_MSNIS_Taglines -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com