| What files do I need to distribute
with my application? You'll need to include APP files, DBFs, and
possibly other files. For a complete listing, see "Foxfire! Application Integration and Distribution" in the Foxfire! online documentation
I've set up my own Preference Set and I'm ready to distribute
it. Is there any easy way to get rid of all the
Foxfire! sample stuff?
If you use the
Preference Set Editor to delete the 'Demo Use of Views' record and then the 'Sample Data
Set' record, you will be prompted with a dialog asking whether you'd like to delete the
sample tables as well. These steps will quickly remove all traces of the samples from your
system.
Running in VFP3,
I'm getting a "versions do not match" error. Why?
Microsoft changed
FOXTOOLS.FLL between v3.0 and v3.0b. The files shipped with Foxfire! (in \3XLIBS) are the v3.0b
ones. When FOXTOOLS is loaded, it seeks out two 'companion' files, DDEREG.EXE and
FLL32_16.DLL. If the v3.0b version of FOXTOOLS finds the v3.0 version of one or more of
the other files, you'll see the version mismatch error. The solution is to copy the two
'companion' files to each directory where you have a copy of FOXTOOLS.FLL (including the
VFP home directory if you're running v3.0 and not v3.0b).
I changed access privileges in the Preference Set, but my
users still have access to the features. What's wrong?
Foxfire! v6.0 now uses User Accounts to establish security level. See the section "User Security and Permissions" in the Foxfire! online documentation
Foxfire! looks fine on my machine, but
on my client's machine some of the dialogs have fonts all scrunched up. What's wrong?
This usually
indicates that either the Andale Mono and/or FoxFont font have not been installed on the client machine. Use the
Windows Control Panel->Fonts applet to ensure that these fonts are available at runtime. If not, install these fonts (they are located in the Foxfire! FONTS subdirectory).
You may need to exit and restart FoxPro and/or Windows to ensure that the font is visible.
I created a
Preference Set with the Setup Wizard. Now I've added a new table to my system. How can I
tell
Foxfire!
about the new table and get it into the existing Preference Set?
Start Foxfire! and switch to the appropriate
Preference Set, then pull down the Tools menu and choose
"System Administrator". The "Import Data Items from File" tool will create new
Data Items in the current Preference Set for all the fields (or just some selected fields)
in your new table. If you add new fields to a table that Foxfire! already knows about, you can
use the same utility program to create new Data Items for just those fields which have
been added
Is there a way to
specify that a report should be landscape regardless of the printer being used?
In VFP, yes. I'm
assuming you're dealing with a custom layout (FRX) here. Set it up the way you want it via
MODI REPO, then save it. Now USE from the command window. The first record is the header
record (for the Windows platform records).1) MODI MEMO EXPR and look for a line reading
"ORIENTATION=" (1=Landscape, 0=Portrait). Erase all the other lines in the memo
and save it. This will force landscape on whatever printer is in use at the other end.2)
MODI MEMO COMMENT and add this string without the quotes:"#DO NOT REPLACE PRINTER
ATTRIBUTES INFORMATION"Note: the text in this string is correct. The help file and
"explain directives" dialog had an *incorrect* version of this text. The correct
text for the other directive is:"#DO NOT REPLACE PRINTER DESTINATION
INFORMATION"When FF sees the #DO NOT..., it bypasses the usual behavior of forcing
the printer attributes based on what the client has installed. Essentially, this means
that you're assuming some of the responsibility for printer/output management. Testtut on
some sample systems, and take a look at allthe other stuff that VFP puts into the EXPR
memo.
I want to report
on two different sets of data which are stored in different locations but contain the same
exact tables and table structures. When I switch from set A to set B and run a Request,
I'm still getting results from the tables in set A. How can I get the results from set B
instead?
By default, Foxfire! leaves tables open after you
have queried them (for performance reasons). This means that if you have a table ABC in
one directory and you query it, then it will be left open. Any subsequent queries
mentioning table ABC will simply use the already-open table, even if you've changed
Preference Sets and/or paths. So when you switch to another Preference Set and run a
Request, you'll still see the ABC data from the original table. If the original table has
been closed before the second query is run, then FoxPro will search for and open the
correct copy of the table.There are two ways to make sure the tables get closed. One is to
write code in the "GLOBAL SETUP" phase of FFCONFIG.PRG (which is called
immediately following a Preference Set change) to explicitly close any of your
application's tables which might be open. This has the least impact on performance
(happens only on first loading a Preference Set), but can involve "hard-coding"
table names.The other is to UNcheck the "Don't Close User DBFs before Execg
Requests" checkbox in the Preference Set Editor "Misc" window. This means
that after EACH Request is run, Foxfire! closes all the non-Foxfire! tables. This works well, but
it can be slow, especially if you have many large tables to open for each
Request.Specifically, in your case, you'll need to go to the Preference Set Editor and
make sure the "Replace user's search path" radiobutton is selected, *NOT* the
"Add to user's search path" one. This way, when you switch Preference Sets, the
path is properly reset so that the old data directory is no longer first on the path. Then
go to the Preference Set Editor "Misc" window and look for the "Don't Close
User DBFs before Executing Requests" checkbox -it should be unchecked. Repeat these
steps for each affected Preference Set.
When I go to add a
new filter to a Request, the list of available data items has a bunch of
"garbage" entries at the top, and some of my Data Items that should be there are
missing. Is this a bug?
Yes, it's a bug - in
FoxPro. This problem results from an intermittent bug in FoxPro's COPY TO ARRAY command
which we have not been able to reproduce consistently. If you're using Foxfire! v3.0, you may want to apply
the fix or the workaround documented below. If you're using Foxfire! v3.0+, the fix has already
been made, so you shouldn't see this problem.As a performance enhancer, after Foxfire! loops through the Data Items
table to build the various arrays of available Data Items, we cache those arrays in the
Preference Set record (field PF_CACHE). Because of the FoxPro bug, in some cases these
arrays become corrupted.FIX: 1. From the command window, open the Preference Set table
(FFPREFER.DBF by default), then issue the command REPLACE ALL PF_CACHE WITH ""
My Data Item's
expression includes a UDF. The UDF works fine from the command window, but when it runs
inside a query, it breaks or returns bad values? Are there special considerations for
running inside a query?
In writing a UDF
that's going to be called as part of the columns clause in a SQL SELECT, there are a few
points to take care about. One is that any changes to work areas, indexes, or record
pointers made during the execution of the UDF must be reversed prior to returning control
to the select. Another is that you must pass any key values as explicit parameters into
the UDF -- the expression is MYUDF(Customer.Cust_ID) -- if you don't pass it in and try to
reference the cust_id field inside the UDF, you may not get the record you're
expecting.When the query is executed, the UDF gets fired TWICE on the first row, once to
figure out the type/size of the return value, then once to get a real value. This may
affect the logic of your UDF (i.e., if you were logging/counting each call, it'd be one
off). It also means that your UDF should always return the same data type at a fixed
length -- use PADR() to ensure this. Otherwise, the column gets dimensioned to whatever
length the first return value has, which may not de enough for other rows.If you put a UDF
in a SQL SELECT, there's an initial "scouting" call to it as the query processor
tries to determine the type/size of the result column. This means that if your UDF is
keeping a count, for instance, it'll be one higher than the actual number of rows
processed. UDFs designed to run inside SQL queries need to accomodate this. The code below
(posted by Pavel Celba on a CompuServe forum) is the slickest way we've seen to do this.It
exploits the fact that all of the "trimming" functions are lobotomized in
"scouting" mode (as during index tag expression evaluation), so they don't
actually trim anything.SELECT myudf() FROM ....procedure myudfIF LEN(SPACE(2)) =
LEN(TRIM(SPACE(2)))* trim was ignored, must be in scouting callRETURN 0000000.00
&& or whatever column should look likeELSE* trim worked, so not in scouting*
.....real work goes here....RETURN whateverENDIFRETURN |
