>Tony,
>
>A couple of things come to mind, but I'll need some more information. Here's the laundry list:
>
>What version of Windows?
>If it's Windows 3.1, is SHARE loaded?
>What version of FoxPro? (I think you said FPW 2.6, right?)
>What network operating system?
>What's the precise text of the indication that FOXTOOLS can't be loaded, or does it just say can't load...?
>Does it trip your error handler?
>
>I've done the following test on a standalone machine with both FPW 2.6 and VFP 5.0. Started two copies of the particular version and set the library in both instances without a problem. This, of course, was done under Win 95. My gut reaction is that this indicates that two executables shouldn't have a problem loading it, especially if they are on separate machines.
>
>I must note, that my statement that I've never had a problem loading FOXTOOLS is incorrect. I did encounter one problem. Recently, I responded to a question regarding network installations, it may have even been to you. If it wasn't, here's what I do. I create an install program that's installed on the user's hard drive and run once the main installtion is completed. It's this program that checks and corrects the user's AUTOEXEC.BAT and CONFIG.SYS files, creates a CONFIG.FPW file in the directory, removes itself from the group, and creates the icon pointing to the actual application. During this process one could also copy FOXTOOLS to that directory. This install program cannot load FOXTOOLS. For some reason, FOXTOOLS cannot be part of a program that runs after the main setup program is completed. I have no idea why this is, but it is not an indication of any problem with loading the library by the main program. Other than this I've never had a problem like the one you describe, and I
>work with WANs too.
>
>One suggestion that I will make to you that applies to this is even hardcoding the path to the library (or any other file, for that matter) is not recommended. Using the HOME() function eliminates the small possibility that a user is running the application from a drive other than F:. Most of the time I indicate a directory by relative path. There are exceptions, in some isntances the path is stored in a table, in some others, variables are used to control the path. This was a significant consideration when I wrote my FPW 2.6 Framework/API.
>
>HTH,
>
>George

George,
Sorry.. This is a VFP 5.0a app.. Started out as a 3.0, but I changed that ^%#(^% real quick <vbg>.. Funny thing is, one person can load it, but other people on different machines can NOT.. Maybe it is a rights issue?? I was thinking of making this file R/O, but didn't know if that would work..

I also thought, okay I have a path statement setup for finding data tables (all free tables, to make sure the data can be accessed by 2.x based apps (Not My Idea, I have been told GOI ), So I thought to include the directory that Foxtools is located in the path and try that...

I have no need for Foxtools right now, but in the future, I would like to be able to use it...

There are prior versions of Foxtools available, so maybe I could just rename foxtools to something else, and try loading it that way, is that a possibility??

Thanx for all your help..

Tony Miller
Vancouver, Wa