Brett Barabash
BBarabash at TappeConstruction.com
Wed May 5 09:48:19 CDT 2004
John, Deep cleansing breaths... We don't want to anyone to be the victim of code rage ;-) Everyone has their hot buttons. Jurgen is obsessed with performance, you are inclined towards rapid development, and I am driven by reliability i.e. making my app as bulletproof as possible. Many unfortunate experiences and frustrated clients later, I made a personal policy of avoiding "built-in" ActiveX DLL's or OCX controls unless: a) They offered functionality that was not easily duplicated through coding. or b) I had a reasonable level of control of the system environment (i.e. know exactly what versions of Windows/Office/IE were installed and didn't have to contend with an overzealous sysadmin). My turning point? I used to use the MS Common Dialog OCX control. Then one day I had a frantic phone call from a customer hundreds of miles away. All of a sudden my app stopped working on her machine. After a lot of Q&A and research, I found that it was due to IE 5 installing a new version of mscomctl.ocx, that was not backwards compatible. Then I found that all of this (free) wasted tech support time was wholly unnecessary, since comdlg32 was just a wrapper around a basic set of API calls. A little research and about an hour tweaking a bas module I downloaded, and I had a module that I just drop into all my projects. Poof! No more ocx hassles. Our office is far from the "concentration camp" that Jurgen worked in, but they are still hyper-sensitive about security. What he stated about sysadmins shutting off its functionality is a valid point. It appears that you don't have these constraints with any of your clients. For example, you were able to convince your clients to not install the current Office service pack, to get around the Outlook email security dialog. I don't dictate the system security policies here. And there is no way in h*ll that I'm taking the heat for overriding their security decisions. Part of my QA process is ensuring that my app won't crap out with an OS upgrade or service pack. Now, back to the FSO. I have never used it in any of my production apps. Not because it is evil, but because I don't find its functionality to be worth the potential deployment pitfalls. Most of the time, my file system needs consist of copying files, deleting files, creating directories and listing directory contents. All of these are already built into VBA (FileCopy, Kill, MkDir, Dir). The remaining (which I don't normally need/use) can be implemented through API calls. Why would I ship my code with a reference to another library when it's already built in? Just doesn't make sense to me. BTW, a recent project involved iterating through a directory of > 5000 textfiles. Dir wouldn't cut it in this case, so I did a little research and ran across this link: Performance Comparison - FSO vs. API http://vbnet.mvps.org/index.html?code/fileapi/fsoapicompare.htm Used it, and it works like a champ! -----Original Message----- From: John W. Colby [mailto:jwcolby at colbyconsulting.com] 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 >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 -------------------------------------------------------------------------------------------------------------------- The information in this email may contain confidential information that is legally privileged. The information is only for the use of the intended recipient(s) named above. If you are not the intended recipient(s), you are hereby notified that any disclosure, copying, distribution, or the taking of any action in regard to the content of this email is strictly prohibited. If transmission is incorrect, unclear, or incomplete, please notify the sender immediately. The authorized recipient(s) of this information is/are prohibited from disclosing this information to any other party and is/are required to destroy the information after its stated need has been fulfilled. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Tappe Construction Co. This footer also confirms that this email message has been scanned for the presence of computer viruses.Scanning of this message and addition of this footer is performed by SurfControl E-mail Filter software in conjunction with virus detection software.