>Can't say I really agree...
>
>One of the reasons VFP is so easy to use is because there are many SIMPLE commands in this product. One liners.
>
>WSH is cool, but compare how many steps it takes to do a number of simple things like renaming a file...
>

Ummm.... 1 + the instantiation of the FSO. Are you telling me it's easier to set a file read-only using just VFP code? Map a drive? Reassign the Windows default printer? How about a little regular expression parsing music, maestro?

There are places where VFP has functions built into it that obviate the need for the various COM objects - and where they exist and do a better job than the COM object, there's no reason to jump in and use the COM solution. Dave Frankenbach and I went down exactly that path with recursing a directory tree a month or two back, and no question, ADIR() ran significantly faster to pull a list of files for a given directory than making thousands of COM references. Of course, ADIR() smokes if you're dain-bread enough to have a directory with over 13,000 entries in it, and if what you're trying to do is pull back the 8.3 format compliant short names, ADIR() doesn't play that game itself...

>More code means more chance to screw something up. Plus size matters. WSH doesn't come for free. You load it you're loading a 4 meg+ runtime. If you're doing stuff like that in a Web server believe me you'll notice the overhead in a hurry...
>

If you need the scripting itself, then there's overhead for the scripting runtime engine. There's no way that making a reference to a discrete COM component from WSH such as Wscript.Network or Scripting.FileSystemObject forces the entire scripting engine to run. Does invoking Shell.Application force you to load all the IE environment? Not unless you use it to reference an instance of InternetExplorer.Application, through one of its Folder objects (not the same thing as a Folder object of the FSO, either.)

If I install WC on my system but never fire its pieces up, what (aside from dollars and diskspace) have I incurred as overhead? I can install WSH and if I never need it and don't fire up scripts or COM objects that came in along with WSH, and the same applies.

OBTW, if I do have WC installed and running but I foolishly fire up some VBScript in a web page run server-side, doesn't that nasty scripting overhead get invoked, too?

I don't advocate replacing functionality in VFP with equivalent functionality in COM objects needlessly, but I do prefer that if a COM solution, used by all the other VS players to implement functionality, is available, that the VFP team spend its efforts elsewhere than adding YAVFPFeature to accomplish this. More code means more errors there, too, and if the COM component's performance is not adequate, there's always the API, or writing a piece of code that exposes a COM or C API style interface to VFP to do the work. I don't want (in fact, I'd run away and hide) a VFP-specific internal implementation of ADSI, for example. I'd be immensely happy if they made it easy for us VFP folks to talk to WMI directly instead...

>I'm not saying we should clamor for getting these features in the product. But I for one I'm glad we have so many of the most common things built in!
>
>+++ Rick ---
>
>>>Hi Kendall..
>>>
>>>If memory serves, I wrote the first article on integrating VFP and the Windows Scripting Host in FoxTalk over a year ago. That said, I don't think there are any VFP-specfic issues with WSH. i.e., the advantages to using WSH in VFP are the same as those for VB, VC, etc, and vice-versa... I did not find any VFP-specfic issues then, and I have not found any now...
>>>
>>
>>JVP:
>>
>>The biggest issue with getting people to add the WSH COM components (and all the other useful stuff) is the mindset that VFP developers seem to have that VFP should do everything that anyone might want to do without such outside foolishness. VFP is this monolithic development environment and we should never have to look over the fence and borrow a tool from the neighbor because it does a nifty, neat and wonderful thing just the way it should be done. If you can't do it in VFP, either there's no reason to do it, or there's a problem with VFP, or we should build this immense Rube Goldberg-esque contraption so that we do not contaminate ourselves with the parrot droppings from other places.
>>
>>I'm a big fan of COM and the scripting environments, and I'd guess that I'm probably pretty competent at exploiting both the COM and scripting capabilities of the tools where applicable. I've got a good foundation in Windows, the Win API, and other programming languages, too. VFP is still my first choice fordeveloping many data-centric systems, is a great tool for hands-on exploration of data, and offers a development environment I'm comfortable with and know well.
>>
>>But, as much as I really like VFP, I drop it like a hot potato when I have to. If I can find something else that can tackle functions cleanly and concisely, and integrates with VFP, I'm happy to add resources to my arsenal, and retire stuff that, while capable of handling the task, I had to maintain for the long term, and it would detailed understanding of and expertise in an otherwise inapplicable skill set. WSH/ADSI/WMI is free, applies to a wide range of environments, and will likely be a part of a base skill set within a couple of years.
>>
>>Administrative tasks for network environments have long been issues that required detailed training and background. Incorporation of simpler access to these tasks, and the ability of an applications programmer to integrate them without needing the detailed and complex direct interaction with the operating systems, instead relying on well-documented, well-understood abstractions, which can be manipulated using tools and techniques already familiar to the application developer, will reduce the need for system administrators for each NOS in house. IOW, I expect to see WSH/ADSI/WMI and similar technologies make it easier to integrate the application into the total enterprise environment, and let the applications developer concentrate on applications issues, and make use of OS services such as access control simple, straightforward and secure, and administered outside of the user application environment if desired. Alternatively, adding users to applications can use the OS services to
>>ensure that necessary access rights are granted, and the OS, through services that extend the registry model to allow user access and configuration details to follow them around, can make certain that necessary system components are made available.
>>
>>IOW, we'd best all stay on top of the changes, not just in the development languages, but in the OS concepts and services that we can draw on for our applications. Personally, I'll start to worry about VFP if the new version encourages us to play entirely inside VFP rather than employing the same widgets all the other VS and Office tools use. I don't want a stronger report writer - I want better, more complete integration with Word and Excel as report tools. I want full participation in ADO, with tools to help us migrate our data access to behave like the other ADO players. DBF/DBC - MSDE file migration....
>>
>>>
>>>
>>>>Hi Ed, George, David and other WSH evangelists!
>>>>
>>>>I would be interested in developing a thread that covers some VFP centric uses for WSH. Obviously, WSH can be used for many environmental and web related tasks, but I'm interested in VFP centric tasks. How can we best apply the WSH in VFP? The pulpit is open<s>!