>I have very recently acquired Foxfire! 3.0 (just got 3.0+ as an upgrade) and have also encountered several "buglets" although nothing really major yet. I haven't really gone 'live' yet but I think we could keep in touch for feedback and problems concerning the product. So far, in a medium complexity app the users who are beta testing it are happy with the freedom they have.

I found that the "REQUESTS","","","MYCONFIG" call doesn't work at all, not just 'for backward compatibility' but it's totally broken. It ignores the configuration file!

You *have* to use the FF_BATCH interface, which is fortunately not as slow as I'd expected.


Also in adding "page n of m" to the reports I ran into problems where the calculation of the number of pages was just WRONG but I suppose we could blame VFP for that?


Fails on ABBREV where alias for the table in the setup of the system was chosen as ABBREVIATIONS.
When setting a filter and then running SHOW SQL, FF says "Expected to find ABBREVIATIONS.DBF" and is looking for ABBREVIATIONS instead of ABBREV.
The SQL-select statement is correct, it looks like the code that validates my selection against the source table is at fault.
Workaround: Edit data items, Filter Options, remove checking!
Click on "Value must be in ABBREVIATIO|" (note the NS won’t fit
)Click on "Button for list of values"
This removes the checking and the query will preview and show SQL


In FoxFire! "Function not registered" is coming from CALLFN() after a REGFN() failed where there was no error trapping for failure.
G_GETPTH line 782 is the point of error
It’s caused by the failure of the regfn() call a few lines above.
It’s suspicious that the SHELL.DLL is being used, not WINAPI and also that foxtools is being used instead of the new DECLARE..DLL syntax.
I could register the function successfully from the command window even though the current registration returned -1.
Then the program worked.
Workaround: Turn off all Excel functions in FoxFire!

In FoxFire! "Function not registered" is coming from CALLFN() after a REGFN() failed where there was no error trapping for failure.
FFREQRUN line 107 is the point of failure, the error appears to be in the regfn() calls above but is not trapped.
It’s suspicious that foxtools is being used instead of the new DECLARE..DLL syntax.

In FoxFire! The error "OLDCSR is not found" is coming from a call to reset the cursor, from hourglass back to pointer I assume.
FNCLEANUP line 1225 is the point of error.
It’s caused by continuing after the above error, which attempts to save the current cursor shape to a variable which is not initialised and when the callfn() fails the variable doesn’t exist.
Apparently there is a systematic error on this system causing REGFN() to fail which I have not been able to track down, despite searching the code for the problem.

Problem is FOXTOOLS version is different from VFP 3.0b shipping.
File sizes identical to the byte, versions from properties the same, FoxToolVer() the same, contents differ checking with FC, update timestamps differ!
Micromega ship 1/Nov/95, MS ship 16/Dec/95.

Replace FOXTOOLS.FLL file in FF30V\3xlibs with the MS version from \VFP and it works, fixing 3 bugs at a stroke !!