// TODO: If you can't read this file properly, make sure that the
//       "Word Wrap" view option is checked (press the F2 key)


@@@ NOTE: This file describes slight problems that existed in the original version 0.99. 2xExplorer has undergone much development since then, and many of the issues mentioned below have long been ironed out. These points are clearly marked with the [$SORTED] tag.


/////////////////////////////////////////////////////////////////////
// SHORTCOMINGS IN 2xExplorer
// Last revision date: 27 Aug 1999

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. ;-)

[$SORTED]
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.

[$SORTED]
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.

[$SORTED]
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... ;-)

[$SORTED]
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
  - [$SORTED] Clipboard Cut/Copy/Paste/Undo for shell objects
  - [$SORTED] 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...

[$SORTED]
* 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.

[$SORTED]
* 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
e-mail: n.bozinis@ic.ac.uk
WWW:    http://personal-pages.ps.ic.ac.uk/~umeca74/
