File: XTree:\Forum archive |Bottom_of_page

XTree Forum archive

# Configured "Command" keys - PROPOSAL PART 2

Posted By: Walter Rassbach <>
Date: Monday, 14 September 1998, at 10:27 p.m.

In Response To: Configured "Command" keys - PROPOSAL PART 1 (Walter Rassbach)

The first part of the actual proposal for enhancing the "configured" command keys consists of some minor "enabling" changes which I think have independent merit even if the main part of the proposal (PART3, to be written) is never implemented... These enabling enhancements are as follows:

1) It is desirable for the %-parameters available (passed to) the .BAT files invoked via the "O"pen command (either "O"pen or alt-"O"pen), which are also used in the alt-/ctrl-"B"atch commands, to be extended. I have proposed this extension in another posting (which can be reached using the link below), but, briefly: (a) provide the "B"atch command %8 to "O"pen's .BAT files, (B) provide the short form extension as %9, (c) Provide the short form path as %10, (d) provide other useful parameters as %11, %12, etc.

. . . ASIDE: Although I did not mention it in the other posting, it might also be nice to have %-parameters that resulted in things like the date, time, file size, etc. These would probably not be all that useful in the .BAT files invoked via Open (too many SHIFT commands), but would be useful in the "command template" mechanism described below... We might want to use mnumonic forms like %D, %T, etc. in the templates below rather than having to remember a lot of "special numbers" (I sometimes have to look with only 8 of them...)

2) Implement a UNIFORM format for "command line" templates and handling throughout ZTree, as follows (leading periods are JUST for formatting this message/posting):

. . a) A "command line template" (or simply "template") consists of plain-text (e.g. [without the quotes], "C:\Tools\Editor.EXE", "/XT", "-add", etc.), %-parameters (e.g., %1 and some special forms I give below), and "markers" (e.g., [LFN], [LFNQ], plus some additional ones), in any order ("markers" are usually the last item, but...).

, , b) A "template" is always used in conjunction with a file "specification" (i.e., drive, path, filename, extension) which is usually the one for the file under the highlight bar and is used to provide the values ZTree fills in when it combines the template and specification for usage. In a few situations, e.g., the "E"dit command executed from the directory/tree view/window, there is no filename/ext (just drive and path) available and ZTree has to prompt for it (for e"X"ecute from the directory level, the filename/ext is just "empty"). Most of the time the resulting combined command line is passed to the Windows API for execution, but, in some cases it is used in other ways, e.g., the ctrl-"B"atch command writes it to the target batch file. Most of the time there is only one file specification but in a few cases (again, ctrl-"B"atch is the only current example) there may be multiple file specifications...

. . d) When ZTree passes the combined command on to the API for execution, it first sets the default/current directory appropriately. For ZTree's e"X"ecute command console window, this is the default directory (ASIDE: In fact, ZTree "locks" its command-console to this directory and a CD [change directory] DOS command has no effect -- This feels like an oversight/bug to me and I would like to suggest that this be corrected... However, when the command-console window is exited via ESC, the directory should revert to where it was when "X" was hit)

. . e) When ZTree processes (for execution) a template which consists ONLY of plain text, it will append the full, short-form, drive, path, filename, and extension for the target file, and then use the line appropriately. For example, a template of "C:\TOOLS\EDIT.EXE" (e.g., configured editor) or "PKZIP -v" (in ARCHIVER.BB2, where the name of the .ZIP file is appended) are such lines. The only exceptions are the lines in the menu system scripts and the prompted command line in ZTree's DOS/command-console window (via e"X"ecute), which is processed unchanged in this case. It may be desirable to specify that anything inside double quotes is "protected" and treated as plain text, with the quotes stripped, but this requires some discussion...

. . f) [EXTENSION:] I would like to see ZTree perform substitutions for environmental (SET) variables in the standard fashion, e.g., %windir% is replaced by (say) C:\W95, etc. In addition, %% should provide the standard escape function... A template containing environmental variables should still be considered to be just plain text (for item (e)) if there are no %-parameters or "markers".

. . g) When a template contains %-parameters, the appropriate strings derived from the file specification are substituted, enclosed in double quotes where necessary. Some method for indicating %10, %11, etc. will need to be provided (see the batch parameter proposal discussed in item (1)).

. . h) When a template contains "markers" (it may also contain %-parameters), the appropriate substitutions are again made. A "marker" consists of some text enclosed in []'s, and I suggest that %[ and %] be used to provide escape sequences for specifying '[' and ']' as plain text. There are currently only two "markers", but I propose that the following markers be provided (the first two are the current ones):

. . . . 1) [LFN] The LFN form of the appropriate drive/path/file/ext without double quotes. (I think this is the way Kim effectively uses it...)

. . . . 2) [LFNQ} As above but with double quotes where needed -- Equivalent to %1. Adding [LFQ] as an additional form might be desirable.

. . . . 3) [SFN] The short form drive/path/file/ext, as for [LFN]

. . . . 4) [LFNS] or maybe [LFN*], [*LF], [*LFN], or [LF*] Equivalent to [LFNQ] when there is only one file specification but used to specify placement of multiple (quoted where necessary) filenames in cases where there are multiple file specifications -- SEE BELOW.

. . . . 5) [SFNS] or maybe [SFN*]/[SF*]/[*SF]/[*SFN] As for (4) but indicating the use of short form names...

. . . . 6) [10], [11], etc. The same as %10, %11, etc. (in fact, might be the only way to specify those "%-parameters"...). Unclear whether [1], [2], etc. should be accepted. Alternatively, these might be specified as [%10], etc.

. . . . 7) [1*], [2*], etc. (or maybe [*1], etc.) Indicate substitution of the appropriate %-parameter, with, in multiple file specification contexts, the approriate multi-item substitution. Note that [1*] is equivalent to [LF*] and [SF*] to [*7]. A further extension might be to use something like [*4.6] to indicate that %4.%6 is to be used, but this makes things a bit complicated and needs to examined...

. . . . 8) [?xy|text] This causes ZTree to perform an open form prompt, with the "text" as the prompt string (a colon and space are appended, and we may want to require quotes if there are spaces or certain special characters), as part of the resolution/combining process (what we are discussing, mainly from point (b) above). The reply to (result of) the prompt is substituted for the marker. The "xy" (I think it must be just 2 alpha characters, case insignificant, but 3 and/or alpha&digit might be OK...) part of the marker is intended to be used as the name for the item in the history file (if omitted, e.g., [?|text], no history), but this part needs to be discussed futher. In multiple file specification situations, only a single prompt is performed, and a marker like [?*xy|text] might be used to indicate that a prompt for each one of the multiple set be done when they are processed individually (e.g., as part of a ctrl-"B"atch command).

. . . . 9) [?xy:text] This causes a special form prompt for a filename, which may include an overriding drive and path, relative to the current path. The "xy" are used for history and the "text" for the prompt string. This form is intended to be like the prompt used for the archive name as part of a ctrl-F5 make-archive command, which could be specified as (we may need quotes?):
. . . . . . . . [?ar:ARCHIVE all tagged files to]
although the additional parts of the first ctrl-F5 prompt (i.e., the text "Enter archive name (no extension)") might be harder (we can probably find a way to do that too...)

. . . . 10) [?xy.ext:text] As for (9) but with a default extension of "ext". Note that there is a REAL difference between [?xy.ext:text] and [?xy:text].ext

. . . . 11) [?xy/text] and [?xy.ext/text] As for (9) and (10) except that the prompt is like the JFC prompt rather than the archive name prompt.

. . . . 12) [?xy\text], etc. prompt for a path just like Copy/Move/etc., with the "point to" function available, etc.

. . . . 13) [?xy=text], etc. prompt for a "rename" string like the filename path of Copy/Move/Rename/etc. (it is not clear that we need this form...).

. . . . . . ASIDE: As part of thinking about this one, it IS clear that we may want to allow the %-parameters (however, allowing "markers" to be embedded in "markers" is probably getting too complicated...) to be used in the "text" string so that, for example, the initial prompt for Copy/Move is something like:
. . . . . . . . [?ws=Copy %4.%5 as]

. . . . 14) [?xy%n:text], [?xy.ext%n:text], [?xy%n:text], etc. These forms perform the same prompting as for (9), (10), and (11), but then substitute just the appropriate string (numbering as for "B"atch files) instead. In addition, ONLY ONE PROMPT is performed for a given "xy" during the combination process, so having something like [?xy%4:text].[?xy%6] does one prompt and then substitutes the two parts...

. . . . 15) [@ext] Is a special marker used in multiple file specification cases and indicates that a temporary file with an extension of "ext" should be built, with one line per file specification (this should be the full LFN drive/path/file/ext, WITHOUT quotes), and the full path/name of the temporary file substituted. in addition, markers like [@ext:%4.%6] or [@ext:Del %1] should result in the obvious lines being written to the temporary file. Note that ZTree often uses a temporary extension of $$and we might default [@] and [@:%1] appropriately... . . . . 16) [NONE] which is used to place a marker on a line to avoid the standard "plain text only" handling described in item (e) above, and the "empty" string is substituted. It is not needed for lines built as part of ZTree's command-console and menu systems. . . . . 17) Possibly some special markers like [DATE}, [TIME], etc. which would provide the current (system) date, time, etc. As suggested above, the date, time, size, attributes, etc. associated with a particular file specification might also be available as %-parameters. . . . . 17) For legacy usage (mainly, for ARCHIVER.BB2) in multiple file situations the string "@list" (without quotes or the []) is needed. It has the same effect as (except for the extra prompt text discussed above): . . . . . . [?ar/ARCHIVE all tagged files to] [@$$$:%7] (or [@$$:%1] if the archiver is marked as [LFNQ] and [@$$$] for an archiver marked as [LFN]). I see no reason to provide any other forms of this one since the "marker" features described above should be sufficient.

. . . There may be some other "markers" which would be useful or needed, but I think the above list covers everything I can think of that ZTree currently does. Although the list look complicated, it should, in fact, not be that hard to implement -- I have written such "parsers" and they ain't that hard... It may be a bit harder to EXPLAIN them, but this is an area where most users will use the simple parts and depend on Kim and "us power users" to provide examples and help (well, KIM should only provide examples, we don't want him getting burdened with providing too much individual level help here!!). Moreover, I have seen things like this provided to "average users" in the past, and with only a bit of reasonable documentation they learn it quite quickly (look at Word or Excel macros...!).

. . i) Some method for specifying breaks in the template, which are used to specify multiple result lines, is needed... A "&&" is used for this separator by the Windows shell (and ZTree probably should not touch it), and "!!" is what XTree used... Another possibility is something like "%/"...

. . I have attempted to combine and integrate the various mechanisms which currently exist in the "B"atch command, Menu system, ARCHIVER.BB2, the configuration screens, etc. into a single paradigm with a significant increase in effective functionality and leaves open possibilities for future enhancements (e.g., additional "markers"). However, note that all of the above is just a set of patterned string manipulations which parses strings into pieces, recognizes some pieces, possibly prompts for additional strings, and pieces strings back together again out of the selected pieces -- This is actually a pretty simple programming task, not rocket science -- it can take a while to write the actual code, but I have designed and written similar things and this one would not be very hard given what I know Kim already has to have in place, e.g., the "complicated" prompts like "point to"...

. . I would like to see this uniform command template functionality applied to everyplace it can/could be in ZTree, including the Viewer/Editor configuration items, the appropriate lines in ARCHIVER.BB2, the template lines provided to the "B"atch commands, the lines entered into the command-console window that ZTree brings up for an e"X"ecute command, the script lines in the menu system, etc. Bringing all of those usages under a single umbrella is SURE to pay big dividends, AND, I think, I have managed to make it "upward compatible" with ALL of the current usages in those places, so nothing will break when it is put in place!!... Moreover, a uniform mechanism would be MUCH simpler for the users and I bet, at least in the long run, for Kim...

3) I would like to see both the internal viewer and ZTree's DOS/command-console made to be DIRECTLY available as "special" invokations of ZTree via command line switches (which MUST BE the first one...), with parameters appropriate to the special usage. Both of these are useful, really "separate" usages (although I would hate to see them actually pulled out in the way TFC has been, the integrated forms are also useful/critical...), which are at least as good as anything available via other programs (anyone know of a "viewer" like ZTree's "V"iew out there?? Isn't ZTree's console window at LEAST as good as the DOS Prompt?? [especially with the enhancements that the command template facility above would provide!!]). Moreover, I think it would allow alt-e"X"ecute to be spawned in a separate command-console window (it is specified to do this but currently doesn't quite, although there are some differences between X and alt-X [e.g., see item (6) below...]).

. . There are also some issues like the handling of the history files which would have to be resolved since the spawned copy of ZTree cannot return its changes to the history back to the original instance (except, maybe, via the actual history file which [I believe] ZTree currently reads once at startup and writes once at shutdown). However, this should not be any harder than dealing with cases where the user opens two copies of ZTree and the current behaviour (the changes made by all but the last one closed are LOST) in that case is probably acceptable for now... Re-read and merge when an instance (either normal or one of these special modes) of ZTree closes would be better, and some kind of periodic "polling" might be a completely reasonable solution. Probably the best solution is to open, read, update, and close the history file every time it is used (and, since it probably stays in the Windows disk cache, maybe not that much of a performance hit...) would allow multiple copies of ZTree to "share" the history file quite cleanly, with updates of the history "instantly" available in all open instance/copies of ZTree...

4) I would like to see alt-"J"FC provided, spawning TFC in a separate window. There are a LOT of times when I have started up a new copy of ZTree just to be able to pull up a JFC window and still do other ZTree stuff while being able to look at the TFC window... Along similar lines, being able to spawn a new (independent) ZTree window/instance directly might be useful, although the amount of information which can be forwarded on the command line used to invoke it is negligible (tagging, logged directories, etc. are out of the question unless Kim wanted to take on all of the problems of shared data structures in a multi-thread environment -- I doubt he's crazy, soooo...)

5) I think something like providing an alt-"V"iew command, which would invoke an external viewer, even though "V"iew invokes the internal one, is a good idea. This is subsumed in the main "configurable command" proposal (in PART 3), but if that proposal is not implemented, I would still like to see this one...

6) In cases where there is no ext.BAT file associated with a file when the "O"pen command is hit, ZTree passes it on to the appropriate Windows API function, which, in the standard Windows fashion, opens it in a new window (try the different effects of using "O"pen on an .EXE file [especially an old DOS or a console application] when there is no EXE.BAT file and when there is one which merely consists of the string @%1). In this case there is no difference AT ALL between the "O"pen and alt-"O"pen functions.

. . I would like to propose that the alt-"O"pen function should, in such cases, invoke the "context menu" API functions instead, i.e., the ones that would be invoked by a RIGHT-click on the file in Explorer (I know it can be done, but I have not dug it out of the SDK yet, and I don't think Kim has either [yet], so, does anyone out there know how and want to tell either me, Kim, or both?)... In addition, although the funcion is generally available from the context menu, I would like to see ctrl-"O"pen bring up the Windows Properties panel for the file.

. . In addition. provide these "O"pen functions (with a plain "O"pen opening the default Windows shell, e.g., Explorer) in the Directory/tree view/window. The EFFECT of the "O"pen command I suggest here is currently available via an alt-X and then entering/executing a "command" consisting of a single period (that's right, just '.' -- for laughs, try ".." too) -- For some reason this does NOT work for the normal e"X"ecute, just for alt-X, although alt-X is still using ZTree's console window, not an independent one...

7) Although these are slightly out-of-context, I would like to see an alt-"B"ranch directory/tree level command implemented, which would act sort of like an internal SUBST command, adding a new directory/tree panel (i.e., something switched/cycled to via ' ') anchored with that directory as the "root" (and maybe an alt-"R"elease option to drop it...) and a display of that path in the displayed "path line" like XTree used to provide... In addition, it would be nice if the "path line" display for an actually SUBST-ed drive could be made to pick up the SUBST like XTree did for SUBST-ed drives under DOS (although even XTree does not seem to do this under W95...).

There may be a few additional enabling/associated items I've left out (or haven't thought of yet) which I will plant in sub-postings under this posting if/when I think of them (and feel free to add your own, although I would like to see any sub-postings here stay at least sort-of "in context"). However, I am going to post this now, make sure it isn't lost, and get on with the main "configurable command" proposal (which, I hope, you are now waiting for with bated breath... ;-) -- Walter

>Batch parameter enhancement PROPOSAL