GFile 2.0A Tech Notes
=====================

Note -  If you have not read the file README.1ST, please do so now. It
	contains particular license terms and warranty information that
	you are implicitly agreeing to by using this program.

Note to GFile 2.0 Users
=======================
As described in detail below, this release of GFile corrects bugs that came to
my attention after GFile 2.0 was released. It is a bug-fix release only, with no
additional capabilities beyond GFile 2.0. As indicated in README.1ST, if
you've registered GFile 2.0, you may use GFile 2.0A with no additional
registration or fee.

Revision History/Program Development Log
========================================
Revision 1.0	3/14/92	Original program completed, written in Visual Basic

Revision 1.1	3/29/92	Fixed several bugs. 
			Added View/Small and Options menu
			Made error handling more robust
			
Revision 1.2	4/5/92	Fixed more bugs.
			Added Disk Info screens
			Changed order of selecting default destination
			for Copy/Move.

Revision 1.3	4/11/92	Fixed bugs.
			Added the ability to save configuration between
			subsequent executions.

Revision 1.4	4/19/92	Changed 'Selected File' listing to give date/time
			and attributes along with filename and length.
			Added 'About...' item to menu.
			Extended the configuation save/load to include the
			drives/directories being displayed, the working
			directory, and the location of GFile on the screen.

Revision 1.5	5/3/92	Completely rewrote the panel display, hilighting and
			directory selection logic to make it more 'visually
			intuitive' - incorporating the idea of an 'active
			pane' and a 'destination pane' similar to many DOS
			file manipulation utilities.
			Fixed several minor bugs.
			Cleaned up the Tab Groups.
			Enhanced performance of the File Info panels.

		6/92	Decided GFile had progressed as far as it could
			using 'Out Of The Box' Visual Basic. Considered
			writing custom controls in C, decided it would be
			be better in the long run to re-write the entire
			program in C. Began development of Revision 2.0.

Revision 2.0 Beta
		9/92	Began beta testing of GFile 2.0 with no
			significant enhancements over 1.5. 

		10/92	Added Program Groups, enhanced command line

		11/92	Added serialized printing, additional small
			enhancements. Decided to make GFile Windows 3.1
			specific (needs toolhelp.dll and shell.dll).

		12/92	'Iconized' Program Item list box. More enhancements
			and bug fixes.

		1/93	More small enhancements, lots of flaky bugs fixed

		2/93	Added browse dialog, put a 'features lock' on the
			program, fixed bugs, began writing documentation. 		

Revision 2.0	2/25/93	Released GFile 2.0

		2/27/93	Murphy's Law strikes. Two days after releasing GFile 2.0
			I discovered/was informed of new bugs. Problems
			discovered and repaired included:

				Memory/resource leaks

				Hourglass cursor not always being removed

				Problem with Serialize Execution occasionally
				starting programs when it shouldn't

				Dropping onto Group List not always working

				Program hanging if 'PMCC' signature in group file
				crossed 512 byte boundary.

				Minor appearance/performance related bugs

Revision 2.0A	3/15/93	Released GFile 2.0A. 

Notes
=====

Although GFile directly reads the group files to implement the Program Item
lists, GFile uses DDE (program to program communication) messages with 
Program manager to make changes in group files. I chose to do it this way 
for a couple of reasons:
	
	1. Safety. If Microsoft were to change the format of group files
	   between 3.1 and 3.2, for example, the worst thing that would
	   happen to GFile is that it wouldn't run. In particular, it would
	   not write incorrectly formatted group files, since it is Program
	   Manager that is actually writing the files.

	2. Efficiency. Although the code to directly manipulate the group
	   files would be faster than communicating with Program Manager,
	   it would certainly also be much much bigger than the 
	   communicating code. Although I'm sure there are people who create
	   dozens of program items a day - they are not the norm. Most of
	   us would rather not waste the disk space re-inventing the wheel -
	   even if it does spin a little bit faster.

The main result of this is that when creating, destroying, or changing
program items, you will see Program Manager come into existence as an icon
(if it is not already running), and then go away again upon completion. If
Program Manager is already running, and is not iconized, it will hide
while the operation is taking place (to prevent unnecessary screen painting
activity), and then re-appear upon completion.


Final Note
==========

Thanks to Randy("I've found a GBug"), Jack, and John. 
Good beta testers are hard to find.
Thanks to Tim. Good political arguments are also hard to find.