 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / March 2005FileSystemObject and Distribution
Anybody know when the FileSystemObject was introduced and whether or not there is anything you need to distribute to end users of your application to get access to it? We have a Word macro as part of our application and I want to use the FileSystemObject in it. We support Word 2000, XP, and 2003. I'm just trying to confirm that I can use it, hopefully without having to distribute any extra DLLs. Thanks in advance for your comments. The File System Object is part of Scripting Runtime, which has been around since at least Windows 2000. It's not the version of Word that is your concern, but the version of Windows. You're not allowed to distribute the Scripting Runtime library to, and I think it wouldn't work, anyway. However I suggest you look at the VB forum archives for any number of threads on why you don't want to do this at all. For one thing, some network security policies prevent its use (you can switch it off through IE's Advanced tab). There are coding standards around that proscribe it too, on the grounds that it is unreliable. Which is no big deal, since there's nothing you can do with the FSO that you can't easily do with ordinary VBA code. Using the FSO is a minor convenience at best. > Anybody know when the FileSystemObject was introduced and whether or not > there is anything you need to distribute to end users of your application [quoted text clipped - 6 lines] > > Thanks in advance for your comments. One of the things I tend to use FileSystemObject for is to quickly check the existence of specific files, folders, drives or shares before trying to do something with them. It seems a lot easier than error handling. I also tend to use it for minor manipulation of simple text files like ini or log files but that is probably just habit on my part. I'm fairly certain that if you restrict the scripting runtime through IE's advanced tab, you're only impacting the running of scripting runtime when script is being hosted by the browser. For example, a vbs or js file being hosted by Windows Script Host is not impacted at all by IE settings. In fact, an HTA file that allows html and scripts ignores IE settings. I suspect that Office applications are likewise independent of IE settings and only require a reference to the scripting run time to have access. The rare user with a PC lacking the scripting runtime library, can download for free at: http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp Steve > The File System Object is part of Scripting Runtime, which has been around > since at least Windows 2000. It's not the version of Word that is your [quoted text clipped - 21 lines] >> >> Thanks in advance for your comments. "Fairly certain" is not good enough if you're distributing something professionally. And in this case wrong, also. > I'm fairly certain that if you restrict the scripting runtime through IE's > advanced tab, you're only impacting the running of scripting runtime when [quoted text clipped - 36 lines] >>> >>> Thanks in advance for your comments. I don't distribute any of my projects professionally but I still wouldn't want to share my work and have it not work for a friend or have my own stuff fail to work for me under certain circumstances. What is the specific setting under the IE settings advanced tab that will shut down the runtime library. I have a few projects I'd like to test to see if I should spend a bit of time updating previous work. Steve > "Fairly certain" is not good enough if you're distributing something > professionally. And in this case wrong, also. [quoted text clipped - 40 lines] >>>> >>>> Thanks in advance for your comments. Jezebel, I searched and searched but could not find any reference to a way IE settings could interfere with my ability to use the FileSystemObject in Word, other Office applications, script hosted by wsh or an hta file. I did come across a few articles that others might find interesting: http://office.microsoft.com/en-us/assistance/HA011379401033.aspx http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=160 http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/dntaloc/html/ office09072000.asp Steve > "Fairly certain" is not good enough if you're distributing something > professionally. And in this case wrong, also. [quoted text clipped - 40 lines] >>>> >>>> Thanks in advance for your comments. Try researching the topic in the main VB forum, where it is thrashed out in detail about once a month. Or look at the security advisories relating to it. For a while Norton was advocating deleting it entirely. Note that I'm not taking a position either way on whether or not this is appropriate; just observing that some organisation DO in fact disable scripting completely. And since, in any case, the convenience of using the FSO is really pretty minor, why bother? In any case, if error-handling is too much trouble for your style of programming, concerns about reliability are moot anyway. > Jezebel, > [quoted text clipped - 55 lines] >>>>> >>>>> Thanks in advance for your comments. Jezebel, I think we agree more than we disagree. It made you a bit angry that I challenged any of your statements so you took a few cheap shots and I shot back. The FileSystemObject can be simpler and quicker than other techniques for a few select tasks but it's probably best avoided for solutions that will be distributed to unknown recipients; on that, we agree. I'm not sure I could go so far as suggesting that the person who posed the original question in this thread should find an alternate approach though. You stated that I was wrong claiming that security settings in IE would not kill the ability to use FileSystemObject in Word or other Office applications. I suspect you discovered that I was correct(if I'm wrong, post a link to a specific example in the VB forum or anywhere else). Some organizations do remove scrrun.dll and take other measures to prevent problems with malicious scripts but that isn't the same as changing a setting in IE. There is a reason that sccrun.dll has been included in Office installations since Office2000 and while there may be reasons for using other techniques the option is there for the taking. Steve > Try researching the topic in the main VB forum, where it is thrashed out > in detail about once a month. Or look at the security advisories relating [quoted text clipped - 66 lines] >>>>>> >>>>>> Thanks in advance for your comments. heated agreement perhaps? I was neither angry nor taking cheap shots, just concerned that you are misleading the OP by posting assertions that are clearly beyond your competence. > Jezebel, > [quoted text clipped - 89 lines] >>>>>>> >>>>>>> Thanks in advance for your comments. OK, so you're saying I'm incompetent. That may be the case I suppose. Please provide the setting in IE that you claim prevents use of the FileSystemObject in VBA. Steve > heated agreement perhaps? I was neither angry nor taking cheap shots, > just concerned that you are misleading the OP by posting assertions that [quoted text clipped - 94 lines] >>>>>>>> >>>>>>>> Thanks in advance for your comments. I've seen the advice to use "regsvr32 scrrun.dll /u" to disable FileSystemObject but if an organization deletes it entirely as you claim Norton advocated at some point in time, how are they able to continue getting Microsoft updates? http://support.microsoft.com/?scid=kb;en-us;836936 Seems like it would be quite a bother to have to download and install scrrun.dll each time MS posted a new security update that needed to be downloaded. I may not be competent to discuss these issues but it seems to me that an organization where they get rid of scripting runtime might be creating as many security issues as they resolve. In any case, I suspect that most security conscious organizations have left scrrun.dll in place on PCs and at most have unregistered the dll (which would be an issue for any VBA use of FileSystemObject, I admit). Steve > Try researching the topic in the main VB forum, where it is thrashed out > in detail about once a month. Or look at the security advisories relating [quoted text clipped - 66 lines] >>>>>> >>>>>> Thanks in advance for your comments. The scripting runtime (scrrun.dll) has been part of a default Windows install since Win98 and beyond and Win2000 and beyond. It also gets downloaded as part of the package by anyone downloaded Windows Script Host (WSH) or vbScript and jScript from Microsoft. My understanding is that it is also included with Office 2000 and beyond to insure availability. Steve > Anybody know when the FileSystemObject was introduced and whether or not > there is anything you need to distribute to end users of your application [quoted text clipped - 6 lines] > > Thanks in advance for your comments. The reason I want to use the FileSystemObject to read text files is because we need to support Unicode text files. The FileSystemObject supports reading Unicode text files nicely. I haven't been able to get the standard Open, Input, Line Input stuff to work with Unicode text files. I've seen others suggest that I read the file as a binary file and then do the conversion, but I'd rather not go through that hassle when the FileSystemObject works very well. > The scripting runtime (scrrun.dll) has been part of a default Windows > install since Win98 and beyond and Win2000 and beyond. It also gets [quoted text clipped - 14 lines] >> >> Thanks in advance for your comments. As you can probably tell from reading my comments through this thread, I see some advantage to using the FileSystemObject myself. I don't think you have to worry about availability since scrrun.dll is distbibuted with Win98SE and beyond, Win2000 and beyond, IE5 and beyond, Office 2000 and beyond, plus all versions of WSH, vbs, and js. Of course, you've probably also seen Jezebel's comments suggesting that I was commenting on matters clearly beyond my level of competence. She might be right; the best I can do is reference MSKB articles and articles by Word MVPs; Jezebel is able to share the fact that the experts in VB forums regularly thrash the concept of using FileSystemObject. Jezebel is so obviously smarter than me, I dare not dispute her opinion!!!!! Steve > The reason I want to use the FileSystemObject to read text files is > because we need to support Unicode text files. The FileSystemObject [quoted text clipped - 25 lines] >>> >>> Thanks in advance for your comments. Jezebel needs to lighten up. > As you can probably tell from reading my comments through this thread, I > see some advantage to using the FileSystemObject myself. I don't think [quoted text clipped - 40 lines] >>>> >>>> Thanks in advance for your comments. I reacted badly to her comments and I apologize for that. I've seen plenty of her posts and she does have far more expertise in VBA than I do. However, your question was about being certain the FileSystemObject would be available and that is something I felt competent to answer. I do a fair amount of scripts and knew that the scripting runtime is available on most PCs, and that security settings on scripts made in IE only affect scripts hosted by the browser and if a user is able to run Windows update you can be confident that the user has not unregistered the library. Steve > Jezebel needs to lighten up. > [quoted text clipped - 42 lines] >>>>> >>>>> Thanks in advance for your comments.
|
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.