home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip: Special Survival Kit
/
Chip_Special_Survival_Kit_fuer_PC_Anwender.iso
/
01tools
/
gfile
/
technote.txt
< prev
Wrap
Text File
|
1994-09-01
|
5KB
|
133 lines
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.