file 'foxtools.fll' does not exist

[USMA99]

We're using a VFP9 "wrapper" program to call an older fox2.6 stand-alone executable from the command-line in the new version. This program works fine for some and we can call the program straight from windows by double-clicking just fine. Strangely, we get a message that foxtools.fll can't be found when doing this on some machines. If we ignore the error it seems to work fine from there.

The fox2.6 version is in the foxpro search path on all machines, we tried putting it right with the called exe and even in the current working directory as per below.

lccurdir=fullpath(curdir())
cmd="copy file x:\programs\foxtools.fll to "+(lccurdir)+"foxtools.fll"
&cmd
[b]run /n x:\programs\program_name[/b]
erase foxtools.fll

Our config.fpw files all look like this:

KEYCOMP = WINDOWS
BELL=OFF
PATH=X:\PROGRAMS;c:\fpw26;"C:\PROGRAM FILES\MICROSOFT VISUAL FOXPRO 9"
CENTURY=ON
CATMAN=OFF
ODOM=5000
TMPFILES=d:\TEMP

We've checked our windows search paths and they're not appreciably different either.

Can someone think of a reason we're getting this error?

Thanks in advance

 

[markros]

Is the error coming from DOS program or from the wrapper?

If the latter, then you can include .fll into the project under copd/API libraries.

I don't remember how is it handled in the DOS version.

 

[USMA99]

The error is actually coming from the old fox26 exe and not the wrapper. I don't actually have the sourcecode (without getting a decompiler) in order to include foxtools.fll into the build but it's aparently being found on some machines and the file is right there with the program so it should be found. I think there has to be something in the environment that old fox2x is referencing and we're not aware of.

 

[dgrewe]

Just to say I asked the Obvious.
1. What version of FoxTools.fll are you trying to run with the 2.6 Program?
2. your "ERASE foxtools.fll" command. Why does it not have "+(lccurdir)+" in front of it. Are you Sure the FoxTools.fll is being erased from the right place ??
3. Why Copy the FLL everytime you start the program. Why not put it there once and leave it there???

My guess is the computers that are not getting the error have a copy of FoxTools.fll in the place the program expectes it to be (or where it can find it) and you erase command in the wrapper is not actually erasing the copy of the FLL the program is finding.

AGAIN, JUST MY WAG.


David W. Grewe Dave

 

[USMA99]

.
Thanks, to answer:

1.) the one that shipped with 2.6 from '94 (and had worked)
2.) it's an oversight, we had the default directory set anyway, but just added the file copy/erase to see if putting the fll file into the default directory helped (which it didn't)
3.) we run this program from different default locations, but if the old fox2.6 program would find the old fll file we wouldn't copy it around at all

The erase is working as intended, we can 'watch' this as it happens

I've tried config files with a path of just the old foxpro or the old fox plus our x:\programs folder where another identical fll copy resides


Is it possible that the old program launched with RUN works from some temp directory (ignoring config.fpw path and default directory entirely) and the fll is not in the temp directory thus it is not found by the old program when it is run this way??

(going into fox2.6 and "DO PROGRAM_NAME" works fine)
.

 

[DSummZZZ]

run /n cmd.exe will tell you what the default directory is.
It probably points to whatever is the the user's default profile.
But like Mike said, there is really no reason to copy and delete the file. Put it where it needs to be a leave it there. It's not that big anyway, and the old app will certainly start faster.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[USMA99]

thanks guys, there was a combination of two things:

-There were search path issues preventing the file from being found and in copying the fll we found in the first place (so we therefore do the copy) I'm not sure we want to put the old fll in the new VFP9 search path in any event.

-the deletion of the fll was occuring before the program launched with the RUN command had returned control to the calling program. So, instead of proceeded as coded above: copy, run, delete, it was actually working as copy, delete, run...

 

[DSummZZZ]

I'm not sure we want to put the old fll in the new VFP9 search path in any event.

Not a problem. It doesn't get loaded or called VFP9 unless you specifically tell it to using "SET LIBRARY". And since most or all of the function calls in foxtools are built into VFP now anyway, there is no reason to load it.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[AndyKr]

Hi Dave

>> And since most or all of the function calls in foxtools are built into VFP now anyway, there is no reason to load it.

Actually that is not even close to true! FoxTools.fll has a huge number of functions that are not included in the native prodcut - specifically the low-level functions for addressing Editing Windows and the Clipboard.

A more accurate statement would be that "a few of the more commonly used functions have been replicated in the native product" For full details of all of the functions (including the low-level ones) you need to get the TOOLHELP.HLP file.

----
Andy Kramek
Visual FoxPro MVP

 

[AndyKr]

The fully documented Help File for FoxTools named "ToolHelp.hlp" was written by George Tasker and is available for free download from the VFP area of the Universal Thread

Title: Extended Foxtools Help
Download ID: 9333

In addition to the 40 or so functions listed in the FoxTools.chm help file this gives details of the "extras":

Editor Functions
_EdActive _EdPaste
_EdCloseFi _EdPosInvi
_EdComment _EdProcList
_EdCopy _EdProperties
_EdCut _EdRedo
_EdDelete _EdRevert
_EdGetChar _EdSelect
_EdGetEnv _EdSendKey
_EdGetLNum _EdSetEnv
_EdGetLPos _EdSetPos
_EdGetPos _EdSkipLin
_EdGetStr _EdStoPos
_EdIndent _EdStoSel
_EdInsert _EdUndo
_EdLastErr _EdUndoOn
_EdOpenFil

Clipboard Functions
CloseClip
CountClipF
EmptyClip
EnumClipFm
GetClipDat
GetClipFmt
IsClipFmt
OpenClip
RegClipFmt
SetClipDat

Exposed Windows API Functions
_FindWindo _WOpen
_FindWindp _WOpenP
_GetWRect _WPutChr
_WAttr _WPutStr
_WBottom _WPosCurso
_WBottomP _WPosCurP
_WClear _WRight
_WClearRec _WRightP
_WClearRep _WScroll
_WClose _WScrollP
_WFindTitl _WSelect
_WFooter _WSendBehi
_WGetCurP _WSetAttr
_WGetCurso _WSetPort
_WGetPort _WSetTitle
_WHeight _WShow
_WHeightP _WSize
_WHide _WSizeP
_WHToHWnd _WTitle
_WLeft _WTop
_WLeftP _WTopP
_WMainWind _WWidth
_WMove _WWidthP
_WMoveP _WZoom
_WOnTop _WSockCleanup
_WSockGetHostByAddr _WSockStartUp

File and Drive Funcitons
AddBS
CleanPath
DefaultExt
DriveType
ForceExt
ForcePath
FoxTouch
JustDrive
JustExt
JustFName
JustPath
JustStem
MkDir
RmDir
ValidPath

and more....

----
Andy Kramek
Visual FoxPro MVP

 

[DSummZZZ]

Sorry I took so long to respond. I was vacationing.

True, there are a ton of functions in FOXTOOLS.FLL that are not in VFP, but I guess my thought was similar to yours. That the more commonly used functions are included.
The ones which are pretty much only useful to Fox 2.x haven't been redone in VFP, since API calls can be used.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm