File: XTree:\Forum archive |Bottom_of_page

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive

Configured "Command" keys - PROPOSAL PART 1

Posted By: Walter Rassbach <>
Date: Sunday, 13 September 1998, at 9:23 a.m.

There are a number of the current command keys which have similar kinds of behaviour but which differ in minor details (this will be clearer from the description below...). I would like to propose that the differences be reduced and that some of the unused "letter" command keys be assigned similar but configurable behaviour.

The current command keys I am discussing, and their behaviour, is as follows (the "FILE:"/"DIR:" labels distinguish key usage in the two types of windows):

"O"pen -- FILE: Standard Windows API open against file under the cursor, unless there is an ext.BAT file, in which case the batch file is invoked with parameters dervived from the highlighted file entry/line. DIR: Unused (was "O"ops in XTree -- NO WAY is Kim ever gonna do THAT one!).
alt-O -- FILE: Same, supposedly in a "new" console window (most of the time it really doesn't matter, even for console/DOS applications, but it does matter when there is an associated .BAT file). DIR: Unused.
ctrl-O -- Unused

"E"dit -- FILE: Execute the configured (via alt-F10) "editor" program in the same console window (assuming it is a console/DOS editor) as ZTree, passing it the highlighted filename (LFN supported). DIR: Same, but prompt for the filename.
alt-E -- FILE: As above except that the "editor" is opened in a separate console window (if it is console/DOS) rather than ZTree's. DIR: Again, as above except a separate window (and prompt for name).
ctrl-E -- Unused

e"X"ecute -- FILE: Open a "ZTree console" window with the initial prompt filled in with the filename under the highlight bar IF/ONLY-IF ZTree recognizes it as an executable file (only executable, not just API-openable like a .TXT file), and otherwise with an initially blank prompt. DIR: The same, but the prompt is, of course, always blank.
alt-X -- FILE/DIR: As above -- This is "supposed" (I thought) to open a separate console window, but does not seem to... -- I assume this is due to the need to stay in the same console window so that the "ZTree console" functionality (e.g., the characteristic display, history functions, etc.) can still be provided (also, since the "ZTree console" is an internal function of ZTree, opening a second console AND thread could be a real nightmare...).
ctrl-X -- Unused.

"V"iew -- FILE: Invoke either the configured external viewer (as for "E"dit) or ZTree's internal viewer if no external viewer is configured. DIR: "V"olume label.
alt-V -- Unused.
ctrl-V -- FILE: Special form of the internal viewer (even if an external one is configured) which will step through all of the tagged files (i.e., viewer command keys to sequence to Next/Prev, Search cascades from file to file, etc.). DIR: Unused

"J"FC -- FILE: Prompt for a "target" file, and invoke TFC.BAT. The standard TFC runs in ZTree's console window. DIR: Unused.
alt-J -- Unused.
ctrl-J -- Unused.

The following is also included because of the way the proposals below fit together...

letter-"B" -- FILE: Unused. DIR: "B"ranch (switches to Branch view)
alt-B -- FILE: "B"atch command (template command line to fill in and execute, with %-parameter substitution). DIR: Unused.
ctrl-B -- FILE: "B"uild-batch, which builds a file of "template command lines", with %-parameters resolved. DIR: "B"ranch-tagged, displaying just the tagged files in the branch.

I, at least, use at least a couple of different editors and viewers in Windows as well as some similar applications like WinZip (mainly because ZTree's archive extraction is [currently] so slow -- Note: My windows default handler for .ZIP is not WinZip, it is ZipMagic, so WinZip is not available from "O"pen...). I have seen postings from others that imply that they would also like some additional commands available, e.g., choice of viewers, etc. Some of this can be accomplished through the use of batch files which prompt the user for a selection and then invoke a selected program, but this can be awkward and is "hard" for users who are not old DOS dinosaurs like me...

I think the basic problem is that the original XTree design in this area is too narrow for current usage and I would like to propose a set of enhancements in this area, which are, hopefully not too much of a burden on Kim.

First, I would like to list some minor proposed "improvements":

a) See if a way can be found to actually open a separate console window for alt-e"X"ecute. Having a separate window available on the desktop in often much more efficient than having to (effectively) switch between the ZTree and console displays. I understand there may be difficulties due to the Windows API, multi-thread considerations, and the history file. I could see using either a separate executable (a cut version of ZTree) or ZTree with a special command line parameter and a separate "ZCONS.HST" file. With that approach it should not be any more difficult than dealing with cases where the user has opened two or more copies of ZTree...

b) [Something like this has been proposed by others] For "V"iew (in FILE), enable the use of alt-"V"iew. First, if the user has configured an external viewer program, using alt-"V"iew differs from "V"iew in exactly the same way as for alt-"E"dit and "E"dit, namely, alt-V opens up an new console window while V invokes the configured viewer in ZTree's window. However, this only matters if the external viewer is a console application.

Because of the fact that ZTree has an internal viewer, it is something of a special case (which I hope to make less "special" below), and the other enhncement I have seen proposed is to have either "V"iew invoke the internal viewer with alt-"V"iew invoking a configured external viewer or vice-versa, i.e., alt-"V"iew always invokes the internal viewer while "V"iew invokes either a configured viewer or the internal one. EVEN IF no other changes are made, I think this last change is certainly worthwhile.

c) The parameters passed to the associated batch file when alt-"O"pen is hit against a file which does have an associated ext.BAT file do not include the standard %8 parameter (the short filename) which is available with the various "B"atch commands. This is probably just an oversight, but it should be corrected.

d) In the configuration item (alt-F10) for the "editor" (and, I assume, the external viewer), one supplies the full path&name for the editor and optionally an "[LFN]" marker to indicate that the editor understands long file names (if the marker is not present ZTree passes a short path and name). The parameter passed to the editor ALWAYS includes the full path, and is quoted (unfortunately, inconsistently between the DIR and FILE cases!) in certain cases (which causes headaches for my old DOS editor...). Note that ZTree also ensures that the default directory is set correctly, which is sufficient for most programs but not for others (thus, full path & name...).

I would like to suggest/propose that the editor (and viewer) configuration lines/items be changed/enhanced to act like a "B"atch line and allow the use of %-parameters. This would allow one to set up the command to be processed precisely. However, to stay backward compatible, we have to also cover cases where a user provides just the path to and name of the executable, possibly with an "[LFN]" marker. The proposed uniform handling for batch/command lines proposed below does provide for this...

e) A number of people have, at various times, asked for a way to be able to select a viewer or editor according to the file extension. The generally suggested solution is to create a batch file for that extension and use the Open command. However, this is not a really satisfying solution since one often wants to use different programs to view and to work with (open) a given type of file, and, this also gives up the mnumonic value of the use of the letter V since one now has to remember that, for this type of file, one uses "O"pen rather than "V"iew to view the file...

f) A number of programs, especially editors and word processors, will accept multiple file names on a single line and open them all simultaneously in separate sub-windows. This seems like an obvious place in which ZTree's tagging functions could be usefully extended.

--------------------------------------------------------------------------
In order to keep this posting from getting too long (and to get it posted before I lose something), I am going to break it here and present the full proposal in a threaded sub-posting. -- Walter

Messages in This Thread

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive is maintained by Mathias Winkler with WebBBS 3.21.

 
---<>---
 
Xtree and XtreeGold are registered trademarks of Symantec Inc.
Other brands and products are trademarks of their respective holders.


FILE COMMANDS:  Directory_view Previous_file   Next_file cuRrent   /Help |Top_of_page