Puzzled by the "New File" action. What's your method?

Help & Support
1

I find DOpus to be "all thumbs" when it comes to creating a new file (e.g. a text file) and then doing something with the new, empty file. GP Software staff tells me the "problem" as I see it is the way DOpus "should" work. This makes we wonder how other users are using the New File feature, and whether you think my approach to the task is reasonable.

The following is what I am doing, and I would appreciate your comments on whether you think DOpus actually has hit on the optimum way of completing the task (or if I'm just going about it the wrong way).

TASK:

The intent is to create a new text file with a specific name, open the file, and write or paste some text in it. Do the following steps in a large, alphabetically sorted directory whose list goes way off the screen. You should be at the top of the list to begin with.

(1) Have no list item selected.

(2) Create a new text file by right by right clicking on the lister's top border or on a folder, then selecting the New File item (it has an arrow indicating a submenu) and the text file item.

(3) This generates a new lister line with name NewTextDocument.txt that is highlighted for renaming. This item is located alphabetically (for that temporary name) in the list, and it should be on the bottom line of the lister (if enough items precede it). Name the file Z.TXT and press "Enter" to accept the new name. Using the Enter key for this natural because the hands are already on the keyboard for renaming.

(4) At this point the file below the temporary name has become visible because the new file has been moved, and that file is in a dotted box. The new Z.TXT file is not visible.

(5) If I press Enter, hoping to load Z.TXT, nothing happens.

(6) Now I have to go find my new file before I can open it. Z is easy to find at or near the end of the list, but other names take more poking around. This disrupts my workflow, I think, unnecessarily.

VARIATIONS:

(7) Try the above exercise over again by starting with a right click on a folder, and the same things happen through step (4). When you press Enter for the second time (step 5), DOpus will load the directory on which you had right clicked, even though that directory had been off-screen at the time, and really isn't the focus of your work.

(8) Start again using either of the right-click starting points, and in step 3, click on the file's icon to save the new filename. NOW SOMETHING DIFFERENT HAPPENS. DOpus follows the renamed Z.TXT to the bottom of the list, and it is the selected file. Now "Enter" or a double click will load it. However, using the mouse to accept a text change I have made on the keyboard is completely unnatural, with the Enter key right there for the purpose.

MY LOGIC:

(a) The Enter key is needed to accept the new filename.

(b) Because there is no point to creating an empty file and then leaving it empty, by engaging the New File process I have made the new file the focus of my work. In fact even DOpus has (briefly) made it the focus of my work during the renaming process.

(c) Using the Enter key a second time is a natural (in fact instinctive) urge for loading the new file. For DOpus' focus on the new file to be lost after this action is inconsistent, and serves no purpose that I can see. I believe DOpus should leave the focus on the new file (i.e. it should be the selected item).

REQUEST FOR YOUR SUPPORT:

I hope you will support me here with a comment asking that this change be made in the program, at least as a configuration option.

AND, it is because I think DOpus is a great program that I raise this point. Just hoping to get this burr out from under the saddle.

2

Took me a while to get around to reading this post as it was so long :slight_smile: but, for what it's worth, I agree that if you've created a new file and pushed return then the new file should still have the focus, wherever it has moved to.

I think it's a conflict with the way the in-line rename mechanism works, where you don't (usually) want the focus to move with the file you renamed (because you often want to continue renaming the file that was after it). I don't know how Opus works internally so I don't know how difficult it would be but some kind of internal flag that says "I'm renaming a new file, jump to the new name when done" would make sense to me.

3

Yeah, even me with my penchant for verbosity smiled a bit at the length of this post... but hey, it's certainly clear as to what the 'issue' is eh?

FWIW, I agree... I'm often annoyed with having to reselect a file that I've either created or renamed when I've wanted to immediately hit Enter and open or execute that file.

At the same time, I often find myself renaming files in succession in the way Nudel has suggested... and in those cases don't WANT to refocus my file selection on the 'just-renamed' file.

Because I may want EITHER file selection result depending on what I'm doing, I think it would be better to have some additional qualifier key made available to control the behavior rather than some HPFM by Opus to guess what I want it to do based on new file vs rename... Like maybe <Ctrl+Enter> on a rename to NOT follow the new filename or something. For instance, I'd want it to reselect the 'just-renamed' file about as often as I'd NOT want it to...

Some other personal prefs/thoughts:

  1. When in inline rename mode... if you want to continue renaming files, DON'T press enter to save the 'current' rename... just use cursor key to move to next/previous file, it's one of the things I love best about Opus inline rename... and the 'change' would be to make after renaming a file ALWAYS cause the file selection to follow the new file name, and not worry about new file vs existing file determination on Opus' part.

  2. An all or nothing option, like a new File Operatoins->Options sub-option to the current 'Automatically sort new and modified files' such as Retain file selection on file rename or something similar (i.e. right now if you DISABLE the existing auto-sort option, the 'issue' becomes a non-issue... your renamed file remains selected and you can hit enter).

  3. As an option 'either' ideas above, maybe an additional option to keep a renamed file 'selected' but not necessarily allow the file display position/focus to 'follow' the file. This way, if you do want to continue renaming files close to the 'old filename' after hitting 'Enter' to save a current rename, at least you don't have to reorient yourself to your original position in the the file display, this would be assuming the sort of options above would in fact cause the focus of the display to 'follow' the new file name.

4

You could get around this for now by using something like:

"C:\Metapad.exe" "{sourcepath$}/{dlgstringS|Enter a name:|temp}.txt"

Not perfect as both text editors I tried insist on prompting for the creation of the new file but it does solve the problem of finding the file to rename.

5

Actually, some of what I wrote above was gibberish. After looking again, renaming an EXISTING file causes the file selection to remain on the renamed file... though the focus (dotted rectangle) remains on the previous psoition of the file before the rename.

Anyhow... that's just to say that the file selection/focus behaviour is different already between 'new files' and renamed 'existing files'.

FWIW:

@set newname={Rs|Specify new filename}
FileType NEW=.txt NEWNAME {$newname}
Select {$newname}.txt

This bound to a hotkey ( <Ctrl+P> here ) seems to sort of produce what you want to have happen. You could just as easily create a context menu entry to do the same... It's prompting you for a name for your new file (rather than purposely handling the new file name in 'inline' rename mode), then sticking that name in a variable, and finally explicitly selecting your new filename... after which you can hit to open that file without having to 'find' it in the list.

The caveat is that the FileType NEWNAME argument still causes the new file to be created in 'inline' rename mode. I thought there was a control for that... it would be nice for it to optionally NOT do that, since the whole point of using the NEWNAME arg is that you're already providing a name to use... I know it's probably that way for a reason though, but maybe we could get a NEWNAME2 arg that just accepts the passed name... and then you'd be golden. Anyhow... all this means is that it requires you to hit key twice... otherwise it does what you want!

Hope that or what Tanis suggested helps...

6

It would be nice if there was a setting that would follow the Windows Explorer behavior. Explorer just creates the file at the end of the list and when you rename it it just stays there unsorted.

7

Ensure the option below is disabled (filter preferences for it).

8

That setting may not have anything to do with a rename, but check it anyway.

9

Thanks kenalcock. That setting does make the file stay at the end after you rename it but once you hit enter to confirm the rename the selection is lost. In Explorer the new file retains the selection.

By the way I am very new to DOpus and so far it's been great customizing it and finding new features every day.

10

I've finally had a chance to play around with the customizations suggested by Tanis and Steje (thanks!). I'm still having the same trouble with both methods, in that I lose the focus on the newly created file.

Tanis said the code he provided solves the problem of finding the new file, but not for me. (Whether it does may depend on how the list is sorted?)

My solution has been to have both Dopus and the competition (PowerDesk) running all the time, and to use PowerDesk for creating new files and Dopus for everything else. But I would really like to clean up my system by uninstalling PowerDesk and also not have that extra icon in my system tray.

BTW, my 60-day trial of Dopus ends tomorrow, and I am buying my copy today. It is definitely the best file manager that is out there, and I just hope this rough edge can be fixed.

I think the best fix would be a "New File" function that can be employed by the user in customization scripts and that allows specifying a filename while retaining the selection focus.

11

My solution solves the problem by eliminating the need to find and select the file. It's should, assuming you have it working as I suggested, just launch your text editor with a prompt to enter a filename...

In your original post you stated that your aim was:

Which is exactly what my button does. It prompts for a filename, launches your text editor (with this new filename as the new file in the editor). You can then type your text and save the file - job done...

Assuming of course your text editor is smart enough to allow a non-existent file on the command line which it will then save to.

12

Tanis,

Right you are about what I said there, and I wasn't explicit enough in that sentence. Your script does solve a big part of my problem, but most often I will want to move the file after I have finished editing it.

So, your script helps a lot and I am grateful to have it, but I would prefer a method that gives the new file the focus and assures that its line is visible on-screen.

Thanks again for your help and for providing the script.

13

If you want to move it after editing - why don't you create in the right place to start with ? :open_mouth:

14

Easier to stay in my "Working" directory where I do nearly everything, and copy or move files to other folders in the tree. Often I file an archive copy of new file elsewhere immediately, but retain the original in my Working directory until I am finished using it as a reference.

It may seem quirky, but that's that's the work mode that has proven most efficient for me.

15

You could add a "Create new text file here" button to the folder context menu which runs something similar to Tanis's command (but instead of passing the text editor a new filename in the current directory it passes a new filename in the directory you right-clicked).

If you do that then you can right-click a folder in the Folder Tree and chose the item to create the new file there. The file display doesn't have to move from your working directory and you never have to move the file.

16

Ah. Interesting idea, and I will give it a try. Thanks.

At present I have Tanis' script attached to Ctrl-N (replacing for that key Create Folder, for which I have a toolbar button).

17

Gasp - :open_mouth:

Leo advocating the use of the bastard Folder Tree? For shame...

18

The folder tree was already being used; I just had an idea of how to use it better. :slight_smile:

I am not as anti-tree as some people, anyway. :slight_smile: I very rarely use folder trees myself and I think that they[1] are generally a poor way to display/navigate directories due to using something of very limited width to display long names in a nested hierarchy, but if other people want to use them then fair enough. I'm not religious about it, either; I toggle the tree on every so often in particular situations where it's useful.

([1] The general concept of a tree control rather than anything specific to the tree in Opus.)

I think trees made more sense back in the 8.3 MS-DOS days where names were never wide and disks were so small that deeply nested directories were unlikely. These days I find them fiddly and annoying. Especially in RegEdit.