home *** CD-ROM | disk | FTP | other *** search
-
- 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.
-
-