Metropoli BBS
VIEWER: bugs MODE: TEXT (ASCII)
		       Known bugs as of 28-August-1994:

	None of the bugs in GFFT itself at this time are serious, and ALL
	can be worked around or ignored.  But it may decrease your
	enjoyment of this program if you are unaware of how to work around
	them.  So, if something doesn't seem to be working correctly, check
	here.

(1) Just after GFFT creates a shell to run GNUPLOT, my machine GURUS!

	Background: The modified version of GNUPLOT provided with
	WinGnuPlot may have this problem if you do not follow the
	INSTALLATION instructions.  (Apparently, if it hasn't been given
	the "set terminal amigascreen" command in .gfft-WinGnuPlot, this
	version of GNUPLOT can GURU, particularly if no CompuGraphic font
	has been installed.)

	Workaround: As the INSTALLATION file says, "If your GNUPLOT is from
	a WinGnuPlot distribution, rename .gfft-WinGnuPlot to .gfft (THIS
	IS VERY IMPORTANT!)."

	Plans: I have been and will keep on trying to get the standard
	GNUPLOT distribution(s) restored to Aminet.  I haven't even been
	able to get a copy of them myself (since version 3.4).  I will also
	try to get the author of WinGnuPlot to fix the problem with the
	modified GNUPLOT included with WinGnuPlot.


(2) Getting help for selected string gadgets in the GFFT Dialog Window
doesn't work for string gadgets which are already selected.

	Background: Normally, to get help for any gadget in the string
	gadget window, all you need do is hold down the Ctrl key and click
	on it.  But this will not work for string gadgets which have
	already been selected.  The help request for them will be ignored.

	Workaround: Deselect the string gadget first by clicking anywhere
	else on the screen.  Then obtain help normally by holding down
	Ctrl while clicking on the string gadget.

	Plans: I do not plan to fix this problem unless someone can tell me
	how to do so easily.  It appears that in order to fix this I would
	have to make the handling of string gadgets in the program
	considerably more complex by handling the editing of string gadgets
	myself (e.g. by adding edit hooks).


(3) Why do I get the error "No Screen" when GNUPLOT is attempting to plot
my spectrum?

	Background: One of the last things GNUPLOT does is to allocate the
	hires custom screen to display your spectrum.  At that point, if
	there is not enough memory available, GNUPLOT will abort leaving
	the "No Screen" message.  This is not necessarily a lack of chip
	memory per se; it is more likely to result from a shortage of total
	memory (fast + chip).  I've run GFFT successfully with up to 8,000
	bins while running other programs using custom screens on an Amiga
	with 2 Mb fast and only 512K chip.

	Workaround:  Try using fewer bins.  If that doesn't help, try
	the suggestions in the 'Low On Memory' section of the INSTALLATION
	file.

	Plans:  I tried to intercept the 'No Screen' error to give the
	user a more useful message, but this was incompatible with
	AmigaDOS 1.3.  Future versions of GFFT are likely to require
	2.0+ and even more memory.


(4) Why do I get the error "Unable to open spectrum file for output!" when
trying to do a second FFT analysis while leaving the plot for the first
analysis in a background screen?

	Background: Although GFFT will now (1.33+) allow you to display
        more than one plot screen at the same time (but see alternatives
        below), during the time when GNUPLOT is reading the data from the
	spectrum file, a spectrum file having the same name cannot be
        re-opened for output.

	Workaround: Wait for GNUPLOT to finish plotting one spectrum before
	beginning to compute the next.  Note that each GNUPLOT session will
	soak up another 400K or more of memory, so consider the options
	below.

	If you want to display several spectra at the same time, you should
	be aware of the "CombinePlots" feature (which is activated by the
	'&' button immediately to the left of the 'Plot' button in the GFFT
	Dialog Window.  This will let you combine any number of spectrum
	plots on the same plot screen where they can be readily compared.
	Or, if you really want to switch between several different plot
	display screens, you can use a screen dump program to save each one
	to a file and then display it with an IFF display program.  That
	will save a lot of memory, and you will have saved each display for
	later use as well (I like to do this).

	Plans: I might "fix" this in a future release, but it won't be a
	high priority unless I hear users with lots of memory to burn
	asking for it.  I will also want to make the CombinePlots feature
	more obvious first (because that is usually the best approach for
	displaying several spectra at once).  I will also probably make
	the error message less cryptic in a future release by testing for
	the specific condition discussed here which usually causes it.


(5) - (6) relate to problems when displaying HELP messages or launching
GNUPLOT from GFFT:

(7) Aliases for MORE in S:Shell-Startup are ignored.

(8) MORE in directories other than <current directory>, C:, or
sys:utilities is not found.

(9) GNUPLOT not found unless in <current directory> or C:.

	Background: Bugs 5-9 are related and due to the the technique used
	by GFFT to create new processes.

	Workaround: Follow instructions in INSTALLATION.  For example, if
	you use a text reader other than MORE, and if you have AmigaDOS 2.0
	or greater, create a link named MORE in your C: directory, or (if
	you only have 1.3) make a copy of it named MORE either in C: or (if
	you run GFFT only from the Workbench) in the same directory as GFFT
	itself.

	Plans: I do not plan to fix these 'problems' (which you will not
	experience if you following the INSTALLATION directions) unless
	someone can tell me how to do easily.  Unfortunately, launching
	other processes is not a very clean area of AmigaDOS, especially
	for programs like GFFT which may be started either from a Shell or
	from the Workbench.  Other techniques I have tried do other bad
	things, such as losing track of the <current directory>.  Those
	other techniques also typically require the creation and use of
	BCPL pointers (@#$%^&*!).  Currently, I use the 'system()' function
	supplied by SAS which is very clean EXCEPT for the fact that it
	causes these problems which could therefore considered to be
	limitations of that function.

	Rather than fixing these current problems, I may add support for
	TOOLTYPES or environmental variables in a future release.


(10) GNUPLOT not found when in same directory as GFFT under AmigaDOS 1.3.

	Background: Under AmigaDOS 1.3, the current directory for the shell
	GFFT creates to run GNUPLOT is SYS:, rather than the directory from
	which GFFT is started.  Under 2.0 and greater, the current
	directory is the one from which GFFT is started (which is where the
	.info file is found if GFFT is started from the Workbench).

	Workaround: Follow the directions in INSTALLATION, which
	specifically advise that you put GNUPLOT in your C: directory,
	where it can always be found.

	If you have no harddrive, and only one floppy drive, you may have
	to make a special boot disk with GNUPLOT (and GFFT, if possible) on
	it.  Be careful about deleting commands (GFFT uses several), and be
	sure to keep sys:utilities/more.  In this case, both GFFT and
	GNUPLOT can be in the root directory of the disk, which will become
	SYS: after booting.  This can be done (I have done it).  See
	discussion of the commands GFFT uses in the INSTALLATION file.

	Plans:  Future releases will probably not support 1.3.

(11) GNUPLOT terminates when I try LogX with Time3D.

	Although this is a GNUPLOT bug (to be fixed in release GNUPLOT
	release 3.6), it is also worked around automatically by GFFT
	starting with GFFT release 1.15.

	Background: Apparently there is a bug in GNUPLOT such that in 3D
	display modes it finds a zero X value to complain about even when
	there is none.
[ RETURN TO DIRECTORY ]