ZEPs -- ZTree Enhancement Proposals

I believe the ZEPs below are mine, but surely some must have been inspired by the fine folks over in the ZTree forum. These ZEPs reflect my established patterns of ZTree usage.

  1. Application Menu (F9)
  2. Directory Management
  3. File management
  4. OS Shell (eXecute)
  5. Macros
  6. Viewer
  7. Usability, User experience, Cosmetics

1. Application Menu (F9)

ZEP002: STATS pane presence in F9

When F9 is invoked in non-Split mode, the STATS pane remains on the screen (for sufficiently wide screens). The STATS information makes sense in FW and DW, but there seems to be no obvious value in keeping it on the screen in F9. It takes up screen estate (from very wide and deep items) and may distract the user.

Removing this XTree legacy would give a more consistent and logical UI. For example, it is not present (and not missed) in the Viewer.

ZEP003: Bookmarking items

Similar to history commands elsewhere in ZTree, bookmarking F9 items would come extremely handy for instant access to commonly used scripts, whether they are currently visible (in an expanded branch) or not.

Hitting F9 followed by Ctrl+% would considerably outperform the (sometimes slow and ambiguous) first-letter navigation.

For example, I currently publish all my web contents from a script called "Web publish %1", to which I navigate with a few 'W' hits. However, there is no guarantee that another item starting with 'W' will be eventually created (this had actually happened in the past). Having a rock-solid Ctrl+W bookmark would instantly solve this problem and allow a simple macro (F9,CTRL_w,RET,FTPpassword,RET) to implement "1-key web publishing".

ZEP004: Item ordinals display in F9

Locating F9 item descriptions is usually a combination of first-letter navigation and some visual effort, but searching for text inside items is practically all manual (guess)work. Since line numbering is essential in managing any type of list, menu items and their contents would greatly benefit if there was a way to somehow tag them with a sequence number.

The extremely useful ordinals display in DW and FW would come handy in F9 as well. Some expanded menus can be very long, and knowing the approximate location of an item could help. When combined together, item contents may go beyond thousands of lines, with no easy way to reach them. My main .ZDB file has close to 9000 lines when viewed with the Viewer and with the Line option activated.

I propose an F9 ordinal display in the usual place, but with the following format:


where item# starts at 1 (the root item) and behaves exactly as in DW -- it's recalculated as branches are expanded and collapsed. It may change at any time.

The line1#-line2# range part that follows should correspond to the absolute line numbers occupied by the item's contents. All scripts are actually segments (a range of lines) from the currently open ZTW.ZAM, and we are here to pinpoint those lines. (Note: ZTW.ZAM is not a pure text file, although it is perfectly viewable in View. All lines can be seen in Alpha mode as numbered when the Line option is on, but many of these "lines" are binary control data. We need to determine how to actually reference these lines with acceptable precision.)

Once the ordinals display is in place, the problem of searching the current F9 can be solved relatively easily, for example, from within F9 (or using eXecute, or View/Searching on ZTW.ZAM directly):

  1. Create an item that searches ZTW.ZAM for a string. Obtain the string from the user with the #ZTset directive. Use a command line utility like FIND or grep to process the request.
  2. Some output should appear on the screen. Note the line number(s) with the hits and locate the items where they occur by looking for the line1#-line2# range on the ordinals display. (Note: This should work OK only if line numbering by ZTree is the same as the numbering used by these external utilities.)
It's irrelevant what approach is used to find the line number(s), but once we know them, it takes just a few navigating keys and some mental work looking for the right line range pair.

It's still largely manual, though. Therefore, we should strive for a more elegant solution to the problem of locating text in F9 that does not rely on ordinals or any special mental effort.

ZEP005: Superfluous border in F9 window (Version 1.50.4)

In Split mode, when F9 is hit, there is an extra border around the F9 window.

With no Split, we see why the second border exists: F9 is inserted into the main DW or FW pane, leaving the STATS pane visible. Here, the extra border makes more sense and is visually acceptable -- it is clear to the user that the F9 window has been displayed inside the DW or FW left pane. It also fits in nicely.

Still, even here the extra border could be eliminated without confusing the user in any way -- on the contrary. There is no extra border in DW and FW after all, so why should there be one around F9? The F9 window could snap into the exact same area as DW and FW, not as an embedded window.

The possible benefits are: somewhat more visual consistency and a gain in screen estate, notably: two full lines for two more menu items to be visible!

ZEP006: F9 content change alert (reminder to hit F3)

Display a '*' someplace (or put in reverse video the words 'ZTreeMenu' on top) the moment F9 items have been modified in any way. This would alert the user to commit changes to the ZTW.ZAM disk file (using F3, or F9,F9).
This feature exists in most environments where editing is taking place, to reduce the risk of losing unsaved work.

ZEP007: Ctrl+Insert: Item description/contents

It seems logical to extend the domain of the extremely useful Ctrl+Insert function from DW and FW to F9. For those using F9 extensively, the following options for populating the Clipboard instantly would be of use:

1. Insert item description
2. Insert item contents
3. Insert both (item description followed by the contents)

Currently, the only way to this is with the mouse, using a file, or, while editing a line, selecting it and using Ctrl+C -- it's slow and boring when done more than a few times in a row...

This would somewhat overlap with the already powerful 'Copy item', 'cOpy scrap' and 'Write > F4 Copy to Clipboard' functions, but would be very consistent with the overall ZTree UI. In addition, F9 being somewhat specific, the stage would be set for inserting other F9 objects into the Clipboard.

ZEP008: First-character navigation beyond 0-9 and A-Z

It is understandable that in DW and FW first-character navigation must be limited to the valid directory and file names. In F9, there is no need for imposing such limitations.

Extending this set to include more printable characters would automatically add more ways of organizing and accessing menu items. (more...)

For example, the user could dedicate special characters to marking different groups of scripts and allowing instant access to them. Rarely used (or hard-to-enter) characters could be used to protect the scripts from accidental access, etc.

Certain characters could be reserved by ZEDTEK for special, future enhancements. For example, items could become non-editable, non-executable, hidden, encrypted or otherwise used by the database system...

ZEP009: Highlighting empty items

This usability feature would save plenty of time trying to view or execute items that are empty. Because of F9's excellent outlining and documenting features, it is not unusual to have a large number of empty items in a database.

Such items would clearly stand out as comments and attract special attention -- or be ignored, depending what one is doing at the time. These items could be either in a different color, or low-lighted (dimmed).

ZEP010: #ZTdb (user-defined)

Implemented as #ZTmenu and %#ZTmenu%

A variable named #ZTdb (or #ZTdatabase, #ZTdbname) would allow a database creator to give the database a unique, internal name.

When a database is loaded, this value becomes available to all scripts in that database, so the scripts will know exactly that they are part of, say, MAIN.ZDB, JOKES.ZDB, TUTORIAL.ZDB, and so on.

This is a user-defined variable, unlike the automatic #ZThome or #ZTdrive ones generated by ZTree.

Active databases are all (currently) associated with a single ZTW.ZAM file. When a database is saved, it is always to ZTW.ZAM, making it easy to lose work. This new token would make the following script code possible and very practical:

Save me to #ZThome\#ZTdb (F9 script)
:: Purpose: Save current database to its associated disk file
:: In this example, the database referenced by the #ZTdb variable is
:: associated with a simple word like 'TOOLS', and it resides
:: in the standard ZTree directory. However, it can also be
:: equated to 'D:\MyDatabases\Testing\TOOLS.ZDB', or
:: '\\SERVER\COMMON\ZTW\CONTACTS.MASTER', and the script adapted accordingly.
COPY #ZThome\ZTW.ZAM #ZThome\#ZTdb.ZDB
ECHO A new version of #ZThome\#ZTdb.ZDB has been created.
ECHO It is now safe to switch to another database.

This will make database switching more reliable, because all databases can reside in their own disk files. The last database used will always be in #ZThome\ZTW.ZAM and be opened by default, so it may be wise to think of #ZThome\ZTW.ZAM as a volatile, temporary, database.

ZEP011: #ZTtoolspath (user-defined)

Similar to #ZTdb, this user-defined variable would point to a disk location like C:\utils, D:\tools, #ZThome\add-ons, or even \\server\common\freeware.

(Of course, the benefits are best seen by those users who organize their tool collections under a single directory branch!)

It is in this area the scripts would look for non-standard utilities (those not found down the standard PATH variable or otherwise). These include archivers, editors, converters, formatters, filters, unix-like tools, etc.

All advanced users tend to accumulate such programs, but there is no agreed upon standard location. Thus, path hard-coding in every single script is often unavoidable. Script portability and database sharing would be less painful if this variable existed.

The reason that not many databases are being shared is the enormous work needed to adapt them to each user's environment.

Since user-defined variables would be defined only once in a given database, such adaptation and script maintenance would become trivial.

#ZTtoolspath (or #ZTtools) could thus be compared to the %ProgramFiles% environment variable of the F9 system.

Implemented as #ZTtools and %#ZTtools%

ZEP012: Startup script

We must think of a way of defining the proposed user variables (such as #ZTdb and #ZTtoolspath) conveniently.

One approach could be to reserve the very first script (or one with a reserved name) as the database "header". Whenever F9 is opened, this script would always be parsed and the variables found there initialized.

The user would edit the "header" script as usual, but executing it manually would never be needed -- ZTree will do it anyway.

In addition to providing the two proposed variables (#ZTdb and #ZTtoolspath), a generic mechanism could be set up to allow the user to define maybe 5 or 10 other variables. These strings would then be used in scripts just like all other #ZTxxx tokens, boosting portability, sharing and simplifying modifications. (more...)

[SPECIAL_HEADER_ITEM] The startup script for the CHESS_E4 database (F9 script)
:: This script will be executed on each F9 invocation. It's purpose
:: is to set global, user-defined variables for use by all scripts.
:: ...
:: #ZTdb=CHESS_E4
:: #ZTtoolspath=C:\utils
:: #ZTuser1=siteadmin
:: #ZTuser2=secretpassword
:: #ZTuser3=\\SERVER\dir\subdir\data\morestuff\
:: #ZTuser4=http://vujnovic.free.fr/ztw/ztw_menu.html
:: #ZTuser5=Please enter your account [anonymous]:
:: #ZTuser6=@echo Press any key to continue, or ^C to abort...
:: #ZTuser7=ftp.mysite.free.fr
:: ...
:: Optional "announcements" and reminders
@ECHO The CHESS_E4 database has been loaded and initialized.
@ECHO If you make any modifications, use F3 to save your work!
@ECHO To update the chess web site with this database, use
@ECHO the "Upload active database to web server" script (Ctrl+W)

Note that the hypothetical "Upload active database to web server" script that exist elsewhere in the database will know how to connect to the FTP server (#ZTuser7) using the access information (#ZTuser1 and #ZTuser2) and the name of the file to send (#ZTdb). This script can be totally generic, because it is driven by external parameters, all residing in the startup script.

Note also that (provided F9 bookmarking gets implemented) the user just needs to hit Ctrl+W (or some other key) to activate the script that will handle sending the current database anywhere while the user continues to work on the database without leaving the F9 environment.

ZEP013: #ZT[userdir] Version 1.??.? (? 2006)

Windows 2000 and XP define the %USERPROFILE% environment variable, allowing scripts to access user's home directories, typically: C:\Documents and Settings\user. Unfortunately, many times we would like to access directly:

"C:\Documents and Settings\user\My Documents"
"C:\Documents and Settings\user\Desktop"
"C:\Documents and Settings\user\Favorites"
"C:\Documents and Settings\user\Start Menu"

or some other subdirectory in the home tree. However, this does not work across language variants, making F9 scripts non-portable. In addition, earlier Windows versions (95, 98) do not even implement %USERPROFILE%.

A certain number of tokens of the #ZT[userdir] type (#ZTmyDocuments, #ZTmyDesktop...) would eliminate large chunks of code used to determine where the most common user files reside. A reliable value, generated directly by an API, would be a of great help. (more...)

Implemented: #ZTDesktop, #ZTFavorites, #ZTMyDocuments, #ZTStartMenu

ZEP014: #ZTyy, #ZTyyyy, #ZTmm, #ZTdd, #ZThh, #ZTmin, #ZTsec

Similar to #ZTos and #ZT[userdir], these tokens would eliminate complex code for generating strings based on the current date and time.

This technique for generating unique file names (for example, 20040326_1833_Tue.LOG) is used frequently, and the code often takes a larger part of the script! This would help script writers a great deal, because time formats tend to vary greatly from version to version, and locale to locale.

A few more date related tokens could be added for completeness: #ZTdow, #ZTdoy, #ZTmoy.

Using #ZTdow (Day of Week) may be used to control tasks that should not be performed on days other than Friday, for example: IF NOT "#ZTdow"=="Fri" GOTO EXIT

Tokens #ZTdoy (1-366) and #ZTmoy (Jan..Dec) may come handy as well...

ZEP015: #ZTos

This token would eliminate slow and hard to maintain scripts like Detecting Windows versions. Parsing the %OS% environment variable and the output from the VER command is hardly efficient and reliable.

Replicating this type of code in many scripts within the same database is currently mandatory and indispensable, for proper functioning and script portability. A reliable value, generated directly by an API, would be a of great help.

ZEP016: Database Management sub-menu (to clean up)

The F9 functionality is built around a single, unique, ZTW.ZAM file. When the entire contents of this file is changed at user's will, many new possibilities suddenly open up.

Currently, managing F9 user "databases" (a collection of *.ZDB files) is achieved with external tools and creative use of F9 and shell scripts.

But this may be risky and time-consuming, and probably the reason why most users never venture into exploring the immense possibilities offered by this unique feature. It would be nice to make these management tasks available naturally and safely from within F9.

In fact, there are only a few operations (creation, switching, searching...) involved, and they could be grouped behind an option added to the F9 bottom menu. A key (F2, for example) could be assigned to open this sub-menu.

Another option is adding a standard CTRL MENU COMMANDS, to match the same UI mechanism found in FW and DW. This second choice would follow nicely the consistency of the UI, but the vastness of the Ctrl+% class of keys could be put to better use in the future: bookmarks to a large number of favorite items!)

Possible options in the proposed Database Management sub-menu:

  1. New Create a new, blank database
    The user provides a 'name' and a #ZThome\'name'.ZDB files is created with the startup script, which will already have the #ZTdb variable defined. The file #ZThome\'name'.ZDB is then copied to #ZThome\ZTW.ZAM and opened as usual, except that the startup script is automatically executed. (In practice, experienced users will probably find it easier to just clone databases by copying .ZDB disk files, renaming them, and editing the startup script...)
  2. Open Open another (switch to) database
    This action first tries to save the active database (to its .ZDB file) and then loads a chosen .ZDB file into memory (creating a new copy of ZTW.ZAM). This switching should be reliable, with sufficient error checking and interaction with the user.
  3. Save Simply copy the current ZTW.ZAM to #ZTdb. If the #ZTdb variable is undefined, do nothing. This gives the user a feeling of safety and a means to manually synchronize the temporary database with the permanent one.
  4. Find Search for text in item description or contents
    Although finding text is doable using various external hacks (thanks to ordinals display -- if implemented), the ideal approach would be to use what is already available and familiar to the user. Namely, searching ZTW.ZAM with the ZTree Viewer would provide the perfect, most logical integration.

    There would be a new option added to View (visible only when ZTW.ZAM is loaded!), that would essentially say: "Go to F9 and select the item that contains the current line". Thus, browsing ZTW.ZAM would be similar to browsing a web page: hit Ctrl+F9 (or some other key) to immediately find yourself in F9 with the current item selected.

    Furthermore, Alt+F9 could launch F9 followed by Alt+E, with the cursor already on the line in question, ready for editing!

  5. Export/Import ZTW.ZAM contents can now be exported/imported to/from pure, editable, text files, thanks to Ben Kent's .VBS scripts. However, providing this from within ZTree would wrap up the database management utilities rather nicely.

2. Directory Management

ZEP101: Default value for Make directory command (more...)

On a daily basis, users need to spend time coming up with temporary directory names when performing tasks like downloading, extracting from archives, installing new products, etc. Because one's attention is elsewhere, this often results in a messy disk organization.

It would be useful for the Make command followed by Enter to create a default directory name, similar to Explorer's "New Folder". But the name should be more useful and meaningful -- "yyyymmddhhnnss", for example. Also, if the new directory is immediately brought into focus, it can be ready for renaming and further work.

This has many benefits: time is saved; even if not renamed, the new directory will reflect the moment it was created; it will sort very well with other such temporary directories next to it. Such names would also serve as reminders that we have unfinished work to do in those directories, which is not easy to spot with names like "x", "temp", "new", "download", "kit", "test", "New Folder"...

3. File Management

ZEP200: File Coloring

Color the files not as a single line, but as distinct filepsec parts (Name, .ext, Size, Date, Attributes), similar to cells in a spreadsheet.
1 2

ZEP201: Hide Statistics/Attr in UnSplit mode (more...)

In Unsplit mode, Statistics cannot be suppressed to free up more space for long media names. Since the code seems to be there already for Split mode (Shift+F8), it would be nice to optionally suppress Statistics in Unsplit as well and gain 21 screen positions.

Split Mode: Statistics None Current Both (None )
UnSplit Mode: Statistics Yes No (No )

One of my older ZEPs (from 80-column days) is optionally hiding the Attr column -- months go by between me looking at them as I don't use them for backups or anything else. If you are dealing with network drives, DVDs, etc., they are not really useful and just take up space. Optionally suppressing them from view would gain 5 more columns. Hence, the above ZEP could be extended to:

Split Mode: Statistics None Current Both (None ) Attributes Visible Invisible (Invisible)
UnSplit Mode: Statistics Yes No (No ) Attributes Visible Invisible (Invisible)

ZEP202: Filespec Date Tokens

The TODAY filespec token is defined by ZTree as "the time since midnight of the current day". It is a shortcut that saves the user from typing in a string like "=2009-12-17", which makes sense only once and, usually, never again. Thanks to simple arithmetic, the expression "TODAY-1" can be used to represent "yesterday". These two date specifications are very useful also due to the fact that they can be bookmarked and retrieved instantly, unlike all other date specifications, which must be hard-coded, with all the risk and inconvenience this brings along.

But in addition to today and yesterday, our lives and activities are strongly delimited and influenced by weeks, months, years, and other intuitive, culturally established, date units. There is no reason why huge amounts of files living on our storage media should not be instantly selectable by those date units as well, when so desired. The feature of selecting and grouping by date (age) is not uncommon in various other tools.

However, TODAY can not reliably reference a time range like "since start of week", since TODAY-N must be changed every 24 hours to remain valid. In addition, the week notion is ambiguous and depends on culture, so there should be a way for users to configure this concept as they please.

Similarly, month and year beginnings currently need to be hard-coded as yyyy-mm-01 and yyyy-01-01 and updated when changes occur (every month). This is extremely risky if an automated procedure depends on this value, and not simply a question of the user being too lazy to type in a new date string once in a while.

Examples of new tokens that could solve this potential risk and make date filespecs saved in histories permanently valid and safe for automation could be:

"week" (SUNDAY seems a good choice, allowing referencing all other days easily with SUNDAY+N)
MONTH (start of current month)
YEAR (start of current year)

This would allow Filespec bookmarks like

T *.*,-*.TMP,>s0,=TODAY
M *.*,-*.TMP,>s0,>=MONTH
Y *.*,-*.TMP,>s0,>=YEAR
W *.*,-*.TMP,>s0,>=SUNDAY+1

to be permanently stored in history.

Date tokens are not simple text shortcuts, but dynamic variables with all the advantages this brings, like programmability!

Macros could grab these entries and perform monthly/yearly archiving, synchronization, searches, etc. For example, it would be trivial to write a macro to ZIP all files from the previous month (and older), then move/delete them, leaving only files less than thirty days ago. Currently, no such macro is possible.

Simple date arithmetic that works with TODAY, should work with the above tokens as well, where it makes sense.

ZTree's New date command allows HH:NN:SS stamps, but the Filespec date specification does not go below 24 hours. Rather, all explicit dates and TODAY default to 00:00:00, as would the proposed SUNDAY, MONTH and YEAR. Hence, if HH:NN:SS is ever introduced into Filespec, the tokens will not break anything.

As a side-effect of enhancing coloring (of file extensions only), ZCOLORS.INI now permits coloring by date (and size) filespecs as well. This allows a visual grouping by date, similar to what Outlook and some other tools do. For example:

=TODAY:Bri Cyan         ; Today
>=TODAY-4:Yellow        ; "week" -- must edit daily
>=2009-02-01:Bri White  ; month -- must edit monthly
>=2009-01-01:White      ; year -- must edit yearly

Here too, hard-coded date filespecs could be eliminated by using date tokens, thus sparing the user from periodically editing what should be a static file.

=TODAY:Bri Cyan
>=MONTH:Bri White
ZEP014: #ZTyy, #ZTyyyy, #ZTmm, #ZTdd, #ZThh, #ZTmin, #ZTsec

ZEP203: Sort by Color

Users who color files by extension (I don't) may find it useful to occasionally sort the object list by color. For example, if you use ZCOLORS.INI to color archives (.arj, .rar, .zip, .7z, .cab...) green, they would then appear next to each other without needing to change/create a filter for them. They could then be more easily processed as a group.

Sorting by color is a natural way of file grouping by yet another criterion, without touching the current filter and other conditions. I saw this decades ago when color appeared on the Mac and still dream about it in my daily work...

To complement Sorting by color, Filtering could also be enhanced to select only objects of certain color(s), giving the user a new file organization playground. Color is the only user-assigned attribute in ZTree, so why not allow Sorting, Filtering, Tagging, etc. based on it?

Another example: I color junction points (dirs) magenta, but it's next to impossible to locate all of them and show in a list. If I could Sort by color, they would appear next to each other instantly. Better yet, if I could Filter/Tag for the "Color=magenta" condition, I could automate the task with a macro.

Web 2.0 is all about hashtags, ZTree is halfway there with "colortagging"!


4. OS Shell (eXecute)

ZEP300: Appending comments to user input

Code quality and maintainability is directly proportional to the amount of commenting and documenting allowed by the environment. The environment may be a programming or scripting language, or any other user input that is stored somewhere for later reuse. If commenting is not dead easy to do, it will be minimal, leading to the eventual loss of code evolution knowledge (human memory issue), inappropriate use (misunderstanding of what the code does) -- a general, permanent, waste of human time in decoding reasons and algorithms over and over!

Of course, even a single command line can often be considered complex code, due to the large number of cryptic options and parameters, piping, redirection, and so on. Just consider archivers and their command line switches.

In ZTree, macros allow simple comments (using the STOP directive), and F9 is ideal for documenting almost anything. Filespec also allows the wonderful "PICS: *.jpg, *.gif, *.tif" commenting construct!

But history entries for Batch, Rename masks, and possibly other commands, do not allow comments, forcing the user to often wonder what an entry exactly does, or sacrifice a history slot to document an adjacent one (which, of course, is no longer adjacent after execution).

Note that in case of eXecute, it is possible to append a "& REM blah blah" or "& :: blah blah" to the command line, so this is taken care of. (Thanks Liviu!)

However, there is no reason to not allow trailing comments (of the "user input ... // comment ..." or similar type) to be entered by the user and stored in all command histories globally. Since '//' may be used by Rename, a better separator is needed.

Before the command is executed, the comment part would be stripped off, so the commands would work just as today, but the user will finally know what some of the obscure, forgotten, entries actually do.

(My experience with OpenVMS command language, DCL, has convinced me of the utmost importance of commenting every single line (if needed, of course). No other shell language seems to offer this, leading to the well-known unix (s)hell, which, among other flaws, does not allow adding a trailing '#' to commands. It only works at the start of line...)

ZEP301: Scrolled-off command output (more...)

Commands generating more than a screenfull of text often need to be recalled and re-issued with a "| MORE" appended. Otherwise, the user has no chance of seeing the output.

This same problem exists in the Windows Command Prompt, but here two possibilities exist:

1. Using the mouse on the scroll bar
2. Alt+SPACE,E,L to invoke a deeply hidden option that enables arrows and PgUp/PgDn to function as scroll keys.

Neither is acceptable: professional terminal emulators usually have keys like Ctrl+ARROWS and Ctrl+PgUp/PgDn pre-wired for this.

Would it be possible to add this feature to ZTree's eXecute?

This could be a feature where it wins over the "DOS box" hands down, and could attract certain power users who must work in command line extensively. Imagine, no more mousing around and forgetting about "| MORE" or "| LESS"?

5. Macros


Adding comments to macros is currently possible only after the STOP token, because anything after it is ignored by the macro processor. This is often sufficient to explain what the macro does.

However, it is often necessary, as in all other programming languages, to embed comments. A pair of tokens like COMMENT_START/COMMENT_END, or some other (preferably shorter) string pair, would tell the macro processor to ignore anything in between.

ZTree allows placing comments in .ZTM files by placing a ';' character at the beginning of a line. This solves the problem of commenting long and complex macros, which should probably be stored in files, rather than executed in direct mode.


There are subtle differences in Windows versions that may break certain macros. For example, the "C:\...\Profiles" directory is "C:\Documents and Settings" in W2K and later. Detecting the correct OS version will help create more portable macros.


This would override the Configuration preference for confirmation in Rename and similar operations, making the macros more portable. In fact, CONFIRM_ON does not make sense in macros, because the number of keystrokes for Yes or No is unknown; all depends on the user's decisions at the time of macro execution. Macros, by definition, must have all the answers already prepared in the macro stream. Hence, any interaction with the user should be delegated to external programs (eXecute) or the application menu (F9).


These directives would save/restore the current state of ZTree. For example, SAVE,SPLIT,...,RESTORE would make sure that the split mode is restored to the original state after the macro exits.

ZEP404: More directives


ZEP405: Repeat counter

Shift+F12 - This is the last F12 key combination left in ZTree. It could be used to prompt the user for a repeat counter and then execute the current macro the specified number of times. This is a much more powerful variant of Alt+F12, but potentially more destructive:

  1. Press Shift+F12 (in DIR or FILE view)
  2. The prompt "Number of times to execute the macro: " appears
  3. The user enters a number and presses Enter, but remains in macro editor/launcher mode, as if F12 had just been pressed!
  4. A macro is executed (N times) via standard Alt+(bookmark), Ctrl+(bookmark) followed by Enter, or history navigation
  5. The repeat counter is reset to 1

In other words, starting the macro execution with F12 (and Alt+F12) forces the repeat counter to 1, whereas Shift+F12 allows for increasing this number. If the user enters "t" or "T", ZTree will set the counter to the number of tagged files -- if there are none, no action will be done, of course.

Note: If, for some reason, Shift+F12 is not available to ZTree, another approach, consistent with ZTree, could be used: an option could be added to the F12 menu (similar to the already existing F3). For example, the option may look similar to F4: 1 time(s). Pressing F4 would prompt the user for a positive integer value. The input is terminated with Enter, and the macro to be executed will be repeated the specified number of times. Pressing ESC instead of Enter at this point would abort the operation and keep the old repeat count value. (It's debatable whether this number should remain sticky or not...)

Macros now accept a counter (F4), so the Shift+F12 key is still free for some future use.

6. Viewer

ZEP500: Matching/non-matching lines cycle

As discussed in this
thread, ZTree's View function would be boosted considerably if the non-matching lines could be hidden from view. Indeed, there should be a cycle to show All (current implementation), Matching-only, and Non-matching-only lines.

This would make View a powerful grep-like utility for gathering only relevant information from a large number of files.

See some workarounds.

ZEP501: Make the Delete key consistent with FW and F7 Implemented

I'm used to deleting files in FW and Autoview (F7) using Delete followed by 'y'. However, when I use (V)iew on a file and conclude that I don't need it, I wish I could hit Delete right there and save a keystroke.

The fact that it works so naturally in Autoview, gives me hope it shouldn't be a problem to add it to (V)iew proper.

7. Usability, User experience, Cosmetics

ZEP601: Extended Statistics window overlay

The ZTree user interface (and visual experience) would be more consistent if the Extended Statistics window (displayed by '/' or '?' keys) did not erase the current display, but overlay it.

In the 25x80 screen mode, the user would see no difference, but "modern" users would see this, instead of a huge blank area surrounding this smallish window.

The overlay should leave the top two lines visible, allowing the user to view current paths and filespecs.

The same ZEP is applicable to the Alt+F10 (Configuration menu) window, which has the same 25x80 geometry. It comes from an external program, ZTW_CFG.EXE, so it's probably not as easy, but it would be more consistent and pleasing to the user if it were an overaly.

ZEP602: Ctrl+Insert ordinal numbers (Version 1.60.13)

Since ordinal numbers are now auto-filled, there is no longer need for this ZEP.

A new Ctrl+Insert option to copy the current file or directory ordinal number to the Clipboard may come handy.

This would make it easy to later reach this object, either manually or via a macro (Alt+\,SHIFT_INS,RET) -- provided no intermediate additions, deletions, or reordering of the list took place.

This would enable keeping track of (anchoring) a certain file, or position in a list. Even if changes do take place, returning to the vicinity of the original point would be useful.

Today, it is not easy to bookmark and later return to a certain object in a list, the way it is doable in almost all editors.

If ordinals become available in F9, this option would apply there as well.

ZEP603: ZTree title modification command

This ZEP is probably obsolete after recently added command line switches (/T0, TD, TF,...).

The ZTree window title bar (and Taskbar button) are not large chunk of screen estate, but are almost always visible. If made more dynamic by allowing the user, as well as ZTree to write to it, some new features will appear:

Several external tools used expressly for this purpose are currently in the making. These tools would not be necessary if somehow the CLI /T(itle) switch processing could be made available to users from within the current ZTree session. Finding a free key is always a problem, but the usage would look like this. The user hits some key and then types in arbitrary text: All of the above strings would be in a history list, as usual, and therefore easy to recall as needed (manually or with a macro).

ZEP604: Insert Spell search string into Filespec prompt

It would be useful to somehow make use of the Spell search string available to Filespec. For example, after building a complicated search mask like *parser*_*v14*2005*.log, the user can navigate to all matching files using PgUp/PgDn and other keys.

However, it seems perfectly reasonable for the user to decide to hide all other files from view, in other words, invoke F(ilespec) and enter the string *parser*_*v14*2005*.log.

Currently, there seems to be no faster way of doing it, other than copying (Ctrl+Insert) the string *while* in search mode, and pasting it (Shift+Insert) into the Filespec prompt. This has the side-effect of destroying the Clipboard.

A function key (like F4) in the Filespec dialog seems like the most direct way of doing it. F3 already inserts the last Filespec used, so the mechanism seems to be there.

Another possibility is extending the F(ilespec) cycle (using TAB), but maybe it is quite long as it is...

ZEP605: Navigating empty objects

Directories can be empty in DW; files can be zero-length in FW; menu items can contain no code (or free-form text) in F9. It is often necessary to locate such object in order to delete them, or understand why they are empty when they shouldn't be!

Rather than locating such objects visually, navigational key(s) could be assigned to cycle through them. Granted, it is easy to locate zero-length files, thanks to Filespec and sorting, but this is not possible for directories and F9 items that are empty.

Highlighting such objects in some way should also be considered as a unique feature: -- it's both a visual alert, and a built-in annotation tool!

ZEP606: Case conversion cycle of selected text

Tweaking today's long directory and file names to look just right is a frequent activity for some ZTree users. This invariably includes converting the case -- which today works fine for entire base or extension parts.

However, portions of the name still must be re-typed in a different case. (By the way, this also applies to the extensive editing taking place in F9 descriptions, and any other editing throughout ZTree.)

Hence, it would be useful if selected characters only in text entry fields could be converted to UPPER/lower/Capitalized using the existing TAB key cycle. If no selection exists, TAB would work as today; otherwise, it would operate on the selected portion only.

(Note that using keys like Ctrl+U, Ctrl+L, and Ctrl+C -- as used in some editors -- is not possible, because this may fetch any existing bookmarked history entries.)

If a selection exists, Shift+Insert (Windows Clipboard paste) fully respects the above rule, so demanding this from the TAB cycle is quite legitimate. In fact, it is an established standard for any editing operations to always apply to the selected object (if any) first.

ZEP607: Sticky display of the average transfer rate

How do you measure the transfer rate of your hard disk, USB key, flash card, or DVD writer? Do you rely on the manufacturer's fact sheet, web forums, Google?

There are so many factors involved that the only valid measurement is the one you obtain in your environment. With real numbers to show, there is no arguing which storage options or network setup works best for you at a given moment!

Because ZTree is often used to move about huge amounts of data locally and remotely, it seems like an almost perfect (but not scientific) tool for measuring data throughput.

ZTree could be enhanced (minimally) to show the transfer rate when performing certain selected commands, like Log, Copy, Move, Mirror, Compare, etc.

ZTree already has useful progress bars and Time Remaining displays, as well as the current transfer rate, but they only give the user a rough feeling of the speed (and then disappear forever); we need data averaged over the entire duration of the operation so that we can compare it against other similar data.

Above all, the information must remain on the screen long enough for the user to glance at and analyze. The information would disappear the moment a subsequent command (or just one of the commands that actually update this display?) is executed.

Since the spinner area is strongly associated with data movement, the last calculated average transfer rate could be displayed right before the spinner.

ZEP608: Non-destructive history fetch operation (more...)

Currently, whatever is fetched from a ZTree history REPLACES the current input line entirely, be it a filespec, search string, date stamp, shell command, rename mask, batch line mask, and so on. This happens with both Ctrl+% and Alt+% history fetch action. If the user wants to preserve current text, he must first save it (Ctrl+Insert), fetch a history item, and then restore the text to a convenient location on the input line (Shift+Insert).

The above is doable, but I propose enhancing the history fetching behaviour with a new mode that will PRESERVE the current input line and allow pasting into it. The user will never worry about losing whatever is on the command line. Consider the following scenario:

What we see is a regular PASTE operation we all understand and love, but the goodies are not coming from the system Clipboard, but rather from ZTree's private (40 or so *per* history) collection of sticky clipboards!

For example, if there is a frequent need to create new batch files, the user would type:


which would result in "test.bat", provided bookmark B points to the ".bat" string.

This would work in all histories, making it possible to insert bits and pieces as needed. This will give us a new way of building, say, the tricky Rename patters, line masks (in Batch), appending "| more" to shell commands, and so on. ZTree would certainly have one of the most advanced and unique line-editing features that brings text re-use to a new level.

The standard Shift+Ins would continue to work, of course, as well as case conversions and all other editing features. (Using Shift+Ins is recommended for pasting in ZTree. Using Ctrl+V should be avoided because it will clash with any entries bookmarked with a "V".)

I've been downloading certain TV shows for the past several years and naming them using the


convention. The problem is that the shows are invariably named "ab.rm", "0205.rm", and similar useless, short names, requiring plenty of time crafting the name. The most boring part is typing in the TV_SHOW_NAMEs, which may be long and have never changed over the years.

I'd like to re-use what I've done dozens of times when renaming a file like "ab.rm" with steps like these:


ZEP609: Selectively remember in command history (more...)

It would be useful to consider a prefix (like '@' used elsewhere) that would prevent Filespecs getting into the history in the first place. Automated tools and macros would not need to worry about flashing screens and history pollution.

Since finding the perfect prefix may not be easy, maybe the best approach would be terminating user input with, say, Ctrl+Enter, rather than Enter as a signal to ZTree to not use the history. This is similar to the already familiar Application Menu and eXecute Ctrl+Enter feature.

For example, many macros today use ...cmd,ENTER,UP,DEL,ESC,ESC as the cleanup mechanism. This could be reduced to a simple ...cmd,CTRL_ENTER!

ZEP610: Taskbar Progress indicator (spinner)

Many of the programs I use update their taskbar button when active. For example, 1by1 (MP3 player) displays the time left and elapsed ("MM:SS, MM:SS Song name") for the current song. This is actually the truncated window title, so not much of the song name is seen -- but I find the time left value useful!

CD burners, file copiers, fragmenters, downloaders, etc., also make use of this regularly.

In ZTree, you need to have the status line (or at least the spinner corner) visible to "check the pulse".

It would be useful (and consistent with the Windows environment) to have the Taskbar button updated for all lengthy operations, freeing the user from switching to/from ZTree for the sole purpose of performing this visual checking.

In addition, if an error occurs, the Taskbar could/should flash, alerting the user to attend to ZTree. How many times have you launched a long operation in the background and forgetten about it, only to find that it stopped very early on?

What I don't know is whether the Taskbar button can be treated separately from the app's window title and if this would mess something else up...

Updated: 20131129
Copyright 2013 vujnovic@free.fr. All rights reserved.