>>Hi all ---
>>
>>This is a major opportunity to call me stupid :-)
>>
>>Anyway, I am working on an application with top-level forms. This is an area new to me; I've just never had the occasion to work this way before. I have _SCREEN=OFF in a CONFIG.FPW file in the root dir of the application. No dice. Screen shows. So, I put _SCREEN.Hide() in the MAIN.PRG of the app. This works but focus doesn't go to my top-level launcher screen so if the user hits Enter, a desktop app launches (the desktop appears to have focus).
>>
>>What the heck am I doing wrong? This is consuming me!!
>
>Hiya Gonz,
>
>Markus, of course, is right about removing the underscore in the config file.
>
>Telling you that isn't, however, the purpose of this post. I made that mistake so often, that I finally wrote a generic routine to create the config file in a post setup executable based on information stored in a table. This also has the advantage of being able to ask the user if they want to put a short cut on their desktop or start menu (as opposed to just the program group).
>
>Anyway, I just wanted to let you know that you weren't alone.
I know I'm preaching to the choir a bit here, but a little more on the joys of the Windows Scripting Host, with some suggestions on how to put it in place in a Setup Wizard install.
A little trick for handling the DCOM and WSH installs - if you start a post-setup executable without SCREEN=OFF, you can actually install DCOM from DCOM95/98 silently if needed, and the reboot the system yourself after your setup routine has finished via ExitWindowsEx(). NT's in trouble in any case if DCOM support isn't loaded.
You can also check if the WSH is in place and install that from a post-setup executable, to make the necessary Automation Objects from it available. I'd install the DCOM and WSH components, and if either required a reboot to install properly, create a RunOnce key to fire a 'second half' of your post-setup executable - I normally assume that a restart is required, but have my app do it rather than the packaged install for either; The second part of your setup that runs after the reboot can safely use SCREEN=OFF, and now all the functionality of Scripting.FileSystemObject, Wscript.Network, and Wscript.Shell (the one I use for shortcut maintenance) is now available as a resource.
All this without having to do something using a tool other than the Setup Wizard!
It is helpful to squirrel away the install directory in a registry entry (or you can get it implied by the location your post-setup executable launches from using JUSTPATH(FULLPATH(SYS(16,0)).
George, please note that even I am capable of learning to use things that came up from FoxTools!
Once the WSH is in place, you can find where you need to place things using the Wscript.Shell's SpecialFolders collection. Some especially useful information is availble in the SpecialFolders collection; the AllUsersDeskTop, AllUsersStartMenu, AllUserPrograms and AllUserStartup are helpful when providing access to your application for all users with profiles enabled or under NT in all cases. The returns from the collection needs to be checked to see if it's null; if so, there is no folder of that description defined (for example, there is no AllUsersDesktop under Win95.)
For people wanting to learn more about the WSH, take a look at the
Wscript object,
WshNetwork object,
WshShell Object,
FileSystemObject object and related entries in the MSDN. A couple of useful URLs might be
http://www.zdnet.com/devhead/resources/scriptlibrary/ and
http://cwashington.netreach.net/home.htmFinally, John Petersen did an article on the automation objects available to VFP from the WSH; it can be downloaded from
http://www.pinpub.com/foxtalk along with the related subscriber downloads for $5.
Windows NT Systems has had an ongoing discussion of the WSH, from a VB/VBScript perspective, in it's Inside the Box column for the past few months, and future articles will deal with even more of the capabilities. It's worth subscribing to if just for this. Their web page is http://www.ntsystems.com
