Do you use HOME() or Foxtools.fll anywhere in the project?

>Here's another in the saga of "The OLE Automation Server From Hell". This has me totally baffled. So much so that I'm thinking of taking a job in the food service industry. This is kind of long, and I trust you'll bear with me.
>
>Yesterday, I got a call about the application that utilizes this in-process DLL I've written. I seems that on one particular PC an OLE automation error was being generated. The data ran fine on other PCs, but not this one.
>
>We hit upon the idea of my writing a VBScript file to access the particular method that was generating the error. So I came up with the following:

Option Explicit
>Dim oOasis, cBeam, cCreel, cErrMsg
>cBeam = "AB"
>cCreel = "C"
>Set oOasis = CreateObject("Oasis.Oasis")
>oOasis.cGauge = "1/12"
>oOasis.cCode = "MS"
>oOasis.nTuftedWidth = 75
>oOasis.nPanels = 2
>oOasis.nYarnFeed = 3
>oOasis.BeamCreelThreadup cBeam, cCreel
>If oOasis.nError = 0 Then
>  MsgBox "No Error Occurred!"
>Else
>  cErrMsg = oOasis.GetErrorMessage()
>  MsgBox cErrMsg
>End If
>oOasis.Destroy
>Set oOasis = Nothing

I save it in the folder where the project was, ran and got "No Error Occurred!". So I copied it to the network, checked to make sure that the DLLs were the same (they were), and ran it. This time I got an error message: "11: Function argument value, type, or count is invalid on line 8 of method explode."
>
>The line referenced in the message is a simple assignment statement, which uses UPPER() to transform the passed parameter to upper case for the local variable. (It gets weird from here, folks.) Check the registry. It's OK, points to the right DLL. On a hunch checked DCOM, and while it was OK re-installed it (Win95B box).
>
>Back to my Win98SE box. Copied the script to a different folder and ran it. Whoops, got the same error! Copied it to the main VFP directory. No error. Checked to make sure everything was registered properly (run-times, etc). Everything was.
>
>OK, copied and registered the stuff to my Win2K Pro box. Same result: OK in the VFP or child foldered, elsewheres the error.
>
>That was yesterday, and it's gotten stranger. That same error was occurring in some situations in production and I was able to duplicate them. So I added the following to the Explode method mentioned in the error message:

IF TYPE("tcPattern") # "C"
>  ERROR "ERROR 9999 Variable type passed is " + TYPE("tcPattern")
>ENDIF

Ran the test from the project directory. No error. Ran it from a different one and it came back that the variable type was "L". OK, that's something at least, but what I don't know.
>
>OK, that method calls Explode twice. Put in an error statement and check before the first call on the variable type and re-compile. Test in the project directory comes back "C". Test in the other folder...throws in error in the Explode method, completely by-passing the error statement before the first call??? OK, unregister and re-register...same thing. When all else fails...RE-BOOT! I re-boot (getting a BSOD, BTW). So scandisk runs, and when I finally get back, I immediately check the registry. Everything's good. Points to the right DLL. Don't start VFP and do the test...the exact same thing happens! The test in the project directory throws the error before Explode is called, the other folder throws the other error in Explode itself, by-passing the previous one as before the re-boot.
>
>I'm about to pack, stomp, clean and whatever else I can think to do with the project and all it's source files (prgs, headers and VCXs). If anyone out there has any inkling of an explanation, I'd sure like to hear it 'cause I'm fresh out of ideas.
>
>tia,