File: XTree:\Forum archive |Bottom_of_page

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

XTree Forum archive

Re: Tab key functionality

Posted By: Walter Rassbach <>
Date: Friday, 28 August 1998, at 9:44 p.m.

In Response To: Re: Tab key functionality (John Gruener)

Hmmm.... Well, I only really meant my suggestion as a THIRD alternative IF Kim decided to put in a configuration option for how to handle TAB/ENTER/etc. during the rename prompt (with the inevitible spill over into Copy/Move), at which point no "compromise" is needed... I recognize that I probably do a lot of things a bit differently from most of the ZTree users, and did not necessarily want to impose my methods on others as the only or default choice (unless there is an unforeseen ground-swell of support :-), I merely wanted to try to have my preferance available if there were options...

In addition to files with an empty name and just an extension (i.e., start with a '.'), I do use a very few -- However, more commonly, I do have a LARGE number of files with multiple '.' characters, both intentional and by default -- e.g., try right-dragging an .EXE file to the desktop and selecting "shortcut" from the context menu, and then look at the filename for the shortcut in ZTree. It should be something like xyz.EXE.LNK. I also use them to handle version info for various things like downloaded packages, old versions of DLLs, etc., etc.

ZTree handles such names fairly well although I have had some discussions with Kim regarding the use of wildcards in either building such names (e.g., via a rename -- a rename to "*. .*" doesn't work well, nor can one rename it back easily [another place where I like my suggested placement...]) or dealing with them in other places...

I had not actually noticed the behaviour you mention (i.e., changing just the extension), but it may be (almost certainly is) just a side-effect (and inadvertent on Kim's part) of the Win API calls -- Kim feeds them an " .XYZ" parameter in the rename call which the API call interprets as just an extension rename, while the same parameter in the copy and move API calls results in exactly that filename... (Kim: This seems right to me, is that what happens?).

However, I also agree that it should be consistent between Rename and Copy/Move, since the filename prompts in the Copy/Move are really renames. I actually LIKE the use of a starting '.' resulting in an extension rename, it clearly has the greatest utility, although I also agree that it should (if intentional) display the filename up to the final period for subsequent editing... -- I.e., take an API glitch and turn it into a nice feature... This does leave the problem of getting explicit " .XYZ" names into ZTree (and, through it to the API calls in a way which does what is intended...).

Of course, that still leaves the other questions about the use of TAB, since what I was hoping for is a FULL filename (with extension) and cursor placement at the right place in the middle, while the use of '.' we are discussing here has an empty extension...


> Walter, how about this compromise:

> Currently, (on Rename only), if you press a "." (period),
> followed by an entry (XYZ) it changes the extension to .XYZ. On
> a "Copy/Move as" if you do the same thing the new file's
> name becomes ".XYZ". This is at best inconsistent, and
> at worst, illegal. I'm not sure whether it's supposed to be permissible
> to start long file names with a period. If you attempt to do this
> with Explorer (W95), it responds with an error stating "You
> must type a file name". But then, this might be a bug in Explorer.
> Can anyone help?

> So instead, if we start with a period, why not duplicate the
> name on the prompt line with the cursor on the first character after
> the last period? This would make Rename work just as it does now,
> but we would see what we're doing. I think Copy/Move should then
> be made to work the same way. This would preclude starting a file
> name with a period, (rarely needed, I would think, even if legal),
> although you could still edit it if you wanted to.

> This would mean having to cursor-left a little more in your
> example, but I think it would work well and be very intuitive.

> This, I think, also has merit, but should, perhaps, be done
> later in a more comprehensive modification, since it has ramifications
> in so many places to be consistent.

> John

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