Brushfire Frequently Asked Questions
(Note: This FAQ is currently geared toward Brushfire 1.5.3 on Windows, and Brushfire 2 on Macintosh Classic. As issues arise for Brushfire 2 on Mac OS X and Windows this page will be updated)
- General Sales
- Script Printing
- Brushfire Execution
- Old Version Issues
- Upgrading Issues
I hate reading User Guides. What do I need to know?
Windows
Brushfire requires you define and configure a Generic/Text printer driver according to the specific settings described in the User Guide. This should only take a few minutes to set up right, and you only need to do it once. The rest is relatively intuitive.
Macintosh
Brushfire requires you to generate script output for analysis. You need to do this first. We provide a copy of Print2Pict, a shareware print driver for Macintosh, to provide this service. You’ll need to install and configure Print2Pict (user Guide is helpful here!). You’ll then want to generate Print2Pict Script Report files for each file of your solution. We provide a file in the Brushfire Extras folder that can help you automate this too. Once you have your script output files, you can launch Brushfire to perform the analysis. We made a design decision to avoid requiring you installing any additional system extensions such as One Click to use Brushfire. This tradeoff means you need to do a few things manually the first time, and then you can have automatic reporting thereafter.
[Mac/Win]: I’m an international customer..will Brushfire work?
Brushfire is currently designed to work with the English version of FileMaker. Early versions of Brushfire were too strict with some date assumptions, that caused problems with non-American date formats. Brushfire Update 1.01 and above supports most international date formats. On the PC, the Brushfire PrintWidget is designed for English language operating systems; however, scripts may still be printed manually and the Brushfire Engine will run.
[Mac/Win]: Will Brushfire run on my computer?
Brushfire for Macintosh will run on a power Macintosh running Classic (8.6 or above) or Mac OS X in compatibility mode.
Brushfire for Windows will run on Windows NT, Windows 2000, and WIndows XP.
Brushfire will not work on Windows 95, Windows 98, Windows ME or natively under Mac OS X. The reasons for this relate to the way Brushfire obtains script data out of FileMaker Pro.
Brushfire requires English Language FileMaker Pro be used to produce the script output.
[Mac/Win] FileMaker Pro has an application error when I print the scripts. Why?
The first step in performing a Brushfire analysis is to output the script text from FileMaker Pro by printing the scripts to a raw text file. This is accomplished on the Mac using Print2Pict, and on Windows by creating a Generic/Text printer driver with certain settings.
When printing all scripts, FileMaker Pro must contend with issues that might be lurking in scripts that have not been touched or modified in a long time, and which might contain embedded data that is no longer relevant. FileMaker, Inc. Engineering is aware of and working on some known bugs in the printing manager functionality to try to address these issues.
In the meantime, many users have reported that recovering a file and then saving a compressed copy of the recovered file will, in many cases, eliminate these problems. Make sure to save your original file and rename the new, recovered and compressed file to the original file name.
Also, we have found that if you work on a copy of your solution and allow FileMaker Pro to crash while printing a problematic file, each time FileMaker Pro crashes it resolves the broken reference to unknown or missing. Eventually, the file will print to completion and you may then analyze the result, locating all the broken scripts and then fix them in your original copy.
Locate the file that caused FileMaker Pro to crash by looking for the most recently modified output file in the Brushfire Script Output folder.
On Windows, when you manually print all scripts for a file, you should save the output to the Brushfire Script Output folder, using any filename you want.
[Win only] Scripts from one file are showing up in the script list for a similarly named file.
In Brushfire 1.5 Windows, there is a known bug with the PrintWidget that prints the scripts for a file twice if there are similarly named files in the solution. You can tell the problem occurs because in the Brushfire report one file will contain its scripts twice, and the similarly named file will contain no scripts listed. The work-around is to replace the file in the Brushfire Script Output folder for the file containing no scripts in the report with a manually created script file. We expect a fix for this problem soon.
[Mac/Win] Brushfire log says no scripts were processed for one or more files.
In the Brushfire log, sometimes solutions show that xx scripts have been read but 0 script lines have been processed. The log should also say why. One of the more common reasons is that the file did not actually contain any script text. Another common reason is that the footer of the first script was not recognized. Brushfire needs to locate the footer of the first page to match up the FileMaker file name with the script output filename. There are two primary reasons footers for the first script are not found:
The combined length of the FileMaker file name and the first script name is too long for Brushfire to properly parse, given the other characters that FMP tosses into the footer. In this case try to create a simple script with a single character name, and a single script line (a comment is fine) and make sure it is the first script in your ScriptMaker list.
The date format in your operating system is one that Brushfire is not recognizing. The Brushfire log should report this case properly; however, if you are a customer from outside the United States, note that Brushfire is expecting reasonably standard US or British style dates.
[Mac/Win]: Brushfire was working fine in Demo mode. Now that I’ve installed my key, it no longer works. What’s up?
Chances are your Brushfire.key file is somehow corrupt. First, be sure the key file is really named exactly that: Brushfire.key. If you are on Windows, make sure the name is not accidentally Brushfire.key.doc or Brushfire.key.txt. If you received your key via one computer and then forwarded the key to another, it is possible the key has extraneous characters at the beginning of each line. Removing those characters, or creating the Brushfire.key file on the original receiving computer and then moving the file will probably solve your problem.
Brushfire appears to halt before it completes the full analysis. Why?
First, make sure you give Brushfire a chance to complete. Sometimes the last phase of the processing takes a minute or so for large files. If your report is done but data is missing or incomplete, check the log to be sure that a file was not skipped. Files may be skipped if the file does not appear to be a proper script output file. The most common problems are as follows:
Mac: To neglect to set the Print2Pict Disposition to Print to Text and to actually print all scripts. You may wish to inspect your Print2Pict file with a program like BBEdit to verify the file contains actual script details rather than records or an image (as hex).
Win:
- To not have set up the #Generic/Text print driver properly during the initial install.
- A FileMaker file may contain no scripts causing Brushfire to get confused when trying to automatically print the scripts.
Brushfire works fine for my smaller solutions, but does not finish on large solutions.
If your Brushfire log shows that the processing is not complete but just halts part way through, and you are running on a Mac, it probably means you need to allocate more RAM to the Brushfire Engine to accommodate your solution. On the Macintosh, Brushfire Engine has a minimum RAM allocation of 8MB, and a preferred allocation of 32 MB, which is large enough for most solutions; however, truly large systems may require more. Similarly, Brushfire reports on large solutions can consume a large amount of disk space so make sure you have lots of room when running large solutions. It is not uncommon for Brushfire to consume 20MB or more for a large report.
I’ve created a Brushfire report using a Mac, but it is not working on a PC or with Netscape. Since this is html, how come?
Brushfire v1.00 had a bug that’s fixed in Brushfire Update 1.01. Download the Update and re-run your analysis.
[Mac only] My Brushfire report is reporting nonexistent errors in script calls to external files. I know the scripts are there.
You may know, but Brushfire does not, unless it can read the Print2Pict file of script steps for that file. The first thing to do is check the log. If it reads:
Processing script steps for file: <file>
0 script statements processed
that’s a clue that no Print2Pict file was read. Another clue is clicking on the file name in the left-hand panel, and finding a blank scripts panel. Brushfire was designed to allow the user to omit some of the Print2Pict files of a solution and still run; however, Brushfire does not specifically note in the report itself that the files were omitted.
I see Perform Script errors but no other errors. Why?
You are probably using an Original v1.0 copy of Brushfire. Brushfire v1.00 checks for unknown script names and files. Brushfire Update 1.01 and above includes checks for unknown and missing relations, fields, layouts, and value lists, and is now available for download.
[Mac only; versions older than 1.5]: I’m getting a strange AppleScript error.
Brushfire on the Macintosh v1.0 through v1.0.4 uses AppleScript for a few initial tasks. Brushfire 1.5 eliminates the use of Applescript and generally is more stable, faster and has more features. First, make sure you are not running Brushfire from the Desktop. Then, check to be sure you have the Standard Additions installed in your Scripting Additions folder within your System folder. If so, and you still have a problem try reinstalling the Standard Additions (by coping it from another computer or reinstalling AppleScript support from the system CD).
How do I upgrade from Brushfire 1.5 to Brushfire 1.5.2?
Download the new Brushfire 1.5.2 package and move your Brushfire.key file from the Brushfire Files directory of Brushfire 1.5 to the Brushfire Files directory of Brushfire 1.5.2. You should also move or archive any existing Brushfire Reports that might be in the old directory.
How do I upgrade from Brushfire 1.0.x to Brushfire 1.5?
Brushfire 1.5 is a paid upgrade from Brushfire 1.0.x
|
