/////////////////////////////////////////////////////////////////////
// SHORTCOMINGS IN 2xExplorer

The pre-release version (v0.99) that you have in your hands is not up
to scratch. A number of details are missing, mainly when it comes to
comparing 2xExplorer with the Win95 Explorer. The code is relatively
stable (it has undergone some really EXTREME testing), yet I wouldn't
preclude the existence of bugs---for example I have not tested 
(sufficiently) the directory reading functions for network drives. 
USE AT YOUR OWN RISK!

Broadly speaking, the present shortcomings in the development of the
program can be split in two categories: they either are little things
that I still haven't done (and know how to tackle) and that I plan to 
incorporate in the release (v1.0) version, OR things that are too big
and I have reservations about fixing them. In all cases, whether I fix
them or not will largely depend on the response that this application 
receives once released out there in the virtual city. Finding a place
in the shareware market would be a powerful incentive for me to quit
the enthusiast/weekend programmer "mode" and really start devoting
full attention to this program. It's the ole' proverbial stick/carrot
thing I guess...


/////////////////////////// "BENIGN" BUGS ///////////////////////////

Below is the list of the known bugs in 2xExplorer at the time of going
to press. Actually "bugs" is too strong a word to describe them, as
none is liable to cause any major upsets during the execution of the 
program---hence the term benign. Moreover, if you know about them you
can take precautions against them.


BB1. 2xExplorer is conscious of changes in the contents of the two 
folders shown its two panes, if they result from a command within the
program itself (e.g. Copy, Move, etc.), and updates the affected views
in an efficient manner---without having to re-read the whole folder 
from scratch. On the other hand it lies completely in the dark about 
changes caused by other concurrently running windows applications,
that happen to modify (e.g. delete) items within any one of its views.
Unfortunately this includes applications launched from 2xExplorer 
itself (including the execution of any batch files).
>>> CAUSE
The reason for this is that I have not discovered an efficient update
mechanizm for detecting such external alterations, that pinpoints the
items that have been affected. Clearly there must be a way to do this
but FindFirstChangeNotification() is hardly suitable, is it?
>>> RESOLUTION
Use the Refresh (Ctrl+R) command to manually re-read folder contents 
that have been externally modified.


BB2. The speed that 2xExplorer reads folder contents is definitely 
not impressive, and may get annoying on machines at the lower range
of the performance bracket. This is especially evident when reading
large directories as "C:\Windows\System".
>>> CAUSE
The method used internally for reading the folders is "by the numbers"
and completely by the book, so as to get icon information, extended 
shell attributes and the like. That involves overworking the OLE2 
interfaces (profiling indicates that in excess of 75% of the execution
is spent in "system" calls). Since the standard Explorer is much 
faster than that, it is clear that Microsoft have kept a few secrets 
up their sleeve in the form of undocumented interfaces. For instance,
how is it possible that a standard shell function call to obtain
traditional file information (modification times etc.) is lacking, 
and one has to resort to age old techniques like FindFirstFile() 
instead?
>>> RESOLUTION
None. Please address any complaints to the Microsoft boffins.


BB3. The shortcut file icons do not have the little arrow overlay icon
shown at the lower left corner, and hence shortcuts could be 
misinterpreted as regular files.
>>> CAUSE
I opted to forgo this feature since the directory reading is slow 
enough as it is! There would be no point in imposing further overheads
in this department, for a feature that is essentially a small detail.
>>> RESOLUTION
None.


BB4. A minimum set of commands/operations is available whenever a pane
of 2xExplorer is browsing a "special" folder like "Desktop" etc.---just
two to be exact: shell-execute (double-click) and item properties. No
special folder is allowed to be either a source or a target of a regular
command as e.g. Copy.
>>> CAUSE
Going through the on-line OLE2 and Shell extensions manuals can be 
really frustrating at times. It is not clear to me what exactly is the
definition of a file (non-shortcut) in a virtual folder and whereabouts
it is physically kept. I just gave up trying to understand!
>>> RESOLUTION
None. 2xExplorer mainly targets real as opposed to virtual folders. The
ability to browse special folders is nevertheless handy as e.g. it
enables accessing network drives etc.


BB5. File sizes above 4GB are not recorded properly. This affects both
individual file status and summary information (e.g. as part of the 
"Folder Data" command output).
>>> CAUSE
The Sunday-programming nature of this whole project/endeavour led me 
to believe that such huge files are rather too rare an eventuality, 
hardly worth my spending (or investing?) time to guard against.
>>> RESOLUTION
None.


BB6. The size totals reported by the "Folder Data" command for each
directory are usually less than the total disk space occupied. This is
particularly evident for root drives of hard disks (e.g. C:\) where the
total bytes plus the disk free space don't add up to the known capacity
of the hard disk.
>>> CAUSE
This behaviour is by design. It is much faster to simply add up the 
byte size of the contained files. The actual physical storage space 
occupied depends on the minimum size of each allocation unit, which in
turn depends on the size of the hard disk---it is not something that 
one has any control over. On the other hands one is always curious 
about the total size of one's projects. For instance, the source code
of 2xExplorer totals at a respectable 446kB, excluding the 
documentation (that's many a weekend away from the pub). Enough to
make one proud, isn't it? ;-)
>>> RESOLUTION
None.


BB7. Files without extensions are not visible in a pane of 2xExplorer
when the visual filter is set to "*.*" as opposed to the default "*"
value. This does not affect folders, which are always visible regardless
of the filter in use.
>>> CAUSE
This behaviour is by design. The wildarg pattern "*.*" strictly
corresponds to file names that contain a dot ('.'), so a name like
"Untitled" without an extension (and hence lacking the dot) is not 
matched by the said pattern. Call me a "Details' enthusiast" if you 
must, but I can get very sensitive about such matters :-|
>>> RESOLUTION
Use the proper "*" filter if you want to view all files.


BB8. After using the splitter handle to change the relative size of the
two panes some keyboard shortcuts---and notably the TAB that cycles
between the panes---don't work, despite the fact that the pain looks
like as if it was "active".
>>> CAUSE
For some mysterious reason the splitter window handle retains the 
keyboard focus after the sizing operation is over. I am completely at a
loss regarding the cause of this problem, and I have lost so much time 
on this minor glitch, to feel completely gutted about it. Therefore I 
have abandoned all effort to rectify it. Any suggestions here would be 
greatly appreciated.
>>> RESOLUTION
Click anywhere within the pane to force its re-activation. Press the
Control key if protection of a selection pattern is an issue.


BB9. The folder history selection combo box on the standard toolbar is
either too small or too large for the current screen resolution and/or 
font size used on your computer.
>>> CAUSE
There are very few aspects of 2xExplorer that are sensitive to the 
desktop screen size---maybe the width of this box is the only one. I
admit that I haven't spent much time worrying about matters that are
linked to the display resolution (cf. the weekend-programming excuses
offered previously).
>>> RESOLUTION
Although the size of the box cannot be altered from within 2xExplorer,
there is a variable called "FolderComboWidth" in [MainFrame Settings]
section in the 2xExplorer.INI file, which is usually located in the
windows folder (C:\Windows or similar). In order to change the width
of the folder history combo box, edit the 2xExplorer.INI file with a
different program (e.g. Notepad) AFTER quitting 2xExplorer. You can 
experiment to find the size (in pixels) that best suits your specific
display settings.


BB10. The column indicator in the viewer/editor window is "fooled" by
TAB characters in the line containing the cursor. Typically a smaller
number than the actual columns will be reported, as each TAB is counted
as a single character instead of translating (expanding) it to the 
equivalent number of spaces it corresponds to.
>>> CAUSE
Sloppy programming by a certain lazy individual. This is such a small
"problem" and the steps required to rectify it are so complicated (and
costly in terms of run-time performance) that I have shelved it instead.
Of course it's all Microsoft's fault for making the access to the text
buffers of edit control windows such an impossible task for Win95.
>>> RESOLUTION
None. I decline to he held responsible for any losses that may arise as
a consequence of this setback. ;-)


BB11. When in overwrite mode in the editor, inserting characters at the
end of the line will overwrite the invisible "carriage return" character,
resulting in the line below being joined at the end of the present one.
>>> CAUSE
All the usual cliches about the Win95 CEdit control apply. Apart from 
the un-cooperability of the said control, most probably I must have
happened to be wearing my "Utmost adherence to precision" hat at the
time of writing that section of the code: when we talk about overwriting
surely this should mean overwriting ALL characters, TABs, carriage 
returns and all, shouldn't it? ;-)
>>> RESOLUTION
None. Care should be exercised when in overwrite mode.


BB12. The editor/viewer windows stubbornly remain above the 2xExplorer
window, hindering the access to the main program's panes, menus, etc.
>>> CAUSE
Each viewer/editor window launched by the F3/F4 commands is NOT a 
separate thread but a modal dialog (like a tool window). This ensures
that the main application can continue running independently of the 
active view/edit sessions. I thought that it would be an interesting
alternative working with modal dialogs for a change, and indeed it was
from a coding point of view. Has anybody wondered why the message pane
on the viewer/editor status bar is not the first (leftmost) one? Just
a little bit of food for thought there... ;-)
>>> RESOLUTION
Use the minimize button of the offending window(s) to send it/them out
of harm's way.


BB13. Actions (file operations) initiated by 2xExplorer cannot be undone
---this is more an omission rather than a bug per se.
>>> CAUSE
Cf. the remarks in the following section regarding the clarity of OLE2
documentation shipped with Visual C++ v4.0.
>>> RESOLUTION
You can use the standard Explorer to undo actions performed by 
2xExplorer (!) when push comes to shove. This rather unexpected 
behaviour is a natural consequence of 2xExplorer performing all file
operations by the book, including the provision for undoing all 
actions. If only the partnership was reciprocal here...


BB14. There is no option in any of the 2xExplorer dialog windows or
property sheets that controls whether user confirmations before Deleting
items will be required or not.
>>> CAUSE
2xExplorer uses the respective shell property for delete confirmations,
so as to achieve a system-wide uniformity. The "Recycle Bin" property 
sheet that can be invoked by clicking on its icon with the right mouse
button enables or disables the delete confirmation dialog window.
>>> RESOLUTION
To enable/disable delete confirmations check/clear the "Display delete
confirmation dialog" box in the "Global" (first) page of the Recycle
Bin's property sheet.


BB15. Sometimes the 2xExplorer window (and/or the editor window) goes
"funny", behaving in an unpredictable manner (e.g. shrinking to an icon
when the maximize control is used, or refusing to be restored after
being minimized). This is not cured even after quitting and restarting
the application.
>>> CAUSE
Clearly I have got the WINDOWPOSITION saving/restoring sequence wrong
at some point, therefore utter crap are stored in the initialization 
file. Unfortunately this bug is so rare and unexpected that I have not
been able to reproduce the conditions that may give rise to it. In 
other words I know next to nothing about why or when it happens. Sorry
about that folks!
>>> RESOLUTION
When this behaviour is detected, the only way out is to delete the 
2xExplorer.INI file and start all over from a tabula rasa, where all 
the properties will be restored to their default values. In case you
want to maintain the previous settings, you can edit the .INI file as
described in BB9, and remove all lines that contain the "WindowPos"
property/variable (there should be two of them).


BB16. When browsing special folders like the "Control Panel" you can 
attempt double-clicking/pressing the return key on many items for as
long as you like without any application being started or folder 
visited. All you get is a variety of miserable explanations of why 
this or that could not be done. These same offending items don't seem
to have any properties, either.
>>> CAUSE
Well, if anybody knows how to launch applications from within special
folders, give us a shout... I don't have a clue (maybe some undocumented
IShellFolder interface function?). Personally I am amazed that links in
the "Desktop" folder can be launched normally as they do (probably 
C:\Windows\Desktop is in the default searched path list).
>>> RESOLUTION
Fortunately there are alternative ways to reach Control Panel elements,
because 2xExplorer is more of 0xExplorer in that department, for all
the assistance you will get from it... ;-)


BB17. Sometimes duplicate items are held in the various drop-down combo
boxes all over the program's dialog windows. This becomes evident when
any drop-down window is opened, exposing the "cloned" embarrassments.
>>> CAUSE
Although (I thought) I had introduced various methods and provisions to
avoid the very eventuality of keeping twice the same e.g. folder name
etc. in the history of such controls, I sure must have missed something,
mustn't I? The thing is that sometimes everything works smoothly but
right at that moment of relief something will always become bent and
twisted. Ain't programmers' life a female dog?
>>> RESOLUTION
Nothing until I figure out the circumstances that cause this rather
innocent annoyance.


////////////// POSSIBLE FUTURE IMPROVEMENTS/EXTENSIONS //////////////

All the following features could be incorporated in future revisions
of 2xExplorer, should there be any popular demand for them.


* STANDARD EXPLORER BEHAVIOUR
Many of the "user-friendliest" of the user-friendly actions that can be
carried out by the standard Win95 Explorer are not available at present
in 2xExplorer. All the following features are missing:
  - File drag/drop operations and communication with Explorer
  - Clipboard Cut/Copy/Paste/Undo for shell objects
  - Shell context menu (right mouse button) support
One could add here the problems of copying from/to special (non-
filesystem) folders and the efficient notification of changes from shell 
mentioned earlier. The OLE2 interfaces relating to the Shell extensions 
(that form the backbone of the whole program) are rather badly 
documented. In fact going through the on-line manuals gives me the 
impression that the documentation was written by an amateur that after 
being overly happy by writing his first "Hello world" program felt 
confident enough to have a crack at OLE programming... Or maybe 
Microsoft wants to keep the whole shell thing secret or something?

The only thing I managed to fathom out is the "Properties" verb and 
that's why the command is available in 2xExplorer. I really don't know 
how to deal with these problems, simply because I don't know how to 
query the shell for the relevant information. Clearly the truth is 
somewhere out there since I have seen many programs that use these 
features successfully (Windows Commander v3.53 pops in mind).


* MODELESS TREE VIEW
There are many occasions where a tree view similar to the left pane
window in the Explorer would be handy. Here I mean something like a
tool-window that would be available at all times (modeless dialog) and
operating in parallel with the two folder detail panes of 2xExplorer, 
as opposed to the modal dialog that is supported in the present version.
This feature would be best utilized if mouse drag/drop operations were
available at the same time.


* HELP SUPPORT
Currently there is minimal "proper" help support, but that's because I
think that there is no such need. The whole package is straightforward
to use and has a variety of self-explanatory information here and there
as necessary (e.g. appearing on the status bar etc.) The features file
(2xExplorer.txt) is available "on-line" from the Help menu as well. 
Note that for this feature to work properly, the help (text) file 
should be located at the same directory as the executable program.

As a programmer, I consider building a proper help framework somewhat
tedious and boring, albeit useful for the newcomer. I reckon it will 
take a lot of "popular demand" to convince me to get down on it...


* EXTENDED EDITOR/VIEWER
The embedded editor/viewer is currently limited to file sizes under 
62kB. Actually problems may be encountered for sizes even smaller than
this. This is a serious problem and there is no simple way to overcome
it. Writing an edit control from scratch is out of the question. I have
a couple of ideas that I could pursue though (using the standard CEdit
and supervising it by swapping buffers whenever scrolling is necessary)
so the matter is not closed yet.


* FIND FILES COMMAND
I wonder, why rewrite a perfectly working item in the standard Win95?
So as to allow jumping to the folder containing a file found, I hear 
you say---and you are right. If convenience is one's target, one should
surely pursue it in all departments?  Well, it is clear that the file
find "utility" in the present version is not up to spec in this or any
other respects for that matter... 


---------------------------------------------------------------------
For your views about these matters (assuming that you'd care to 
comment of course) and/or bug reports you can contact:

(Mr.) Nikos Bozinis
1E Northstead Road, Tulse Hill
London SW2 3JN, United Kingdom

e-mail: n.bozinis@ic.ac.uk
 