dandv

1. Run a Find that produces many results on the Find: panel. 2. Suppose you want to look at a specific file, so you remove uninteresting files from the results, as you view them, by pressing Ctrl+Del. 3. Now actually want to delete a file from the results. 4. Notice how all the files you removed have now reappeared. This is highly annoying because much work done for filtering out uninteresting files will be lost.

Used the test version some more. After finding some files, Shift+Enter from the Find panel not only focuses on the file (in the opposite panel), but also calculates the execution time of some command, as when the prompt were {} after pressing Alt+/ twice.

Weird :) Thanks for the test version. It does work correctly now. Hoping for a new release soon :)

1. Press Alt+Home on a file. 2. Press ESC (suppose you don't want to launch any actions from the context menu) 3. Notice how Windows will launch the file, as if running `start !.!` I tried to upload a screenshot but I'm getting the error "Error Upload failed. Please ask the administrator to ensure the uploads directory is writeable"

AH, thanks for fixing this in the March release! There's only one minor issue left: This works as expected: This launches execution in a new cmd window and doesn't redirect to the file. The only difference is the missing space after the filename.

I've also reported this here, but I just found out a worse case: piping: perl myscript.pl | more This will produce an odd error: 'C:\strawberry\perl\bin' is not recognized as an internal or external command, operable program or batch file. My perl.exe is in c:\strawberry\perl\bin\perl.exe indeed, so looks like NDN does some wrong parsing. Please fix this, since NDN is unique among file managers in its ability to execute commands and have the output in its own window (Ctrl+O).

Try to change the attributes of a file with access denied (e.g. opened by another application). NDN will not issue any warning, and if you examine the attributes of the file, they will be unchanged.

A regression in this version compared to the previous one: running .PL executables that are are %PATHEXT% (and probably other non-exe/com/bat executables) launches a new cmd window. I have added .PL to %PATHEXT% because so that I can use many Perl scripts easily from the command line: (I don't have to type perl in front of "reverse.pl lines.txt"). However in this version, running that command will create a new cmd window that will close as soon as the script exits, so I can't see its output. In Explorer -> Tools -> Foldr Options -> File Types, for PL files I have an Open action which runs This has worked perfectly up to this NDN version by running the script "under" NDN, and showing the output in the Ctrl+O window.

I've noticed that NDN executes the archiver in order to read 7Z archives (usually NDN has native support for archives). Is there a chance of improving 7Z support in the following ways? 1. If NDN doesn't find the 7Z executable, when enter an archive the error message will be "No files in archive", which misleads the user into thinking the archive is corrupt. 2. Executing 7Z every time is a bit slow. Maybe it's possible to load 7z.dll? 3. Reading archives using 7-Zip 9 beta no longer works (its archive listing output is interpreted as only one string: "Name").

Hey AH, thanks for the Xmas version! That directory is ?%UserProfile%\Eigene Dateien\ :)

When comparing directories (Ctrl+C), if one of the panels is an archive and the "Compare content" box is checked, NDN will just marks files as being different. It would be nice if either the "Compare context" checkbox were disabled, or if NDN actually extracted the files for comparison.

1. Select 2 or more non-empty directories 2. Try to delete the directories and answer "Yes" to the "Do you wish to delete these files" prompt, then to the "OK to delete N files" prompt. 3. You will get a new dialog box for each non-empty directory (if the corresponding preference was checked in Confirmations). When the first such dialog appears ("Directory ... is not empty. Do you wish to delete it"), press Esc. 4. NDN will display an "Abort operation" Confirm dialog. 5. Press No to not abort the operation. NDN will still abort it.

Here's my scenario: In C:\stuff, I have a bunch of directories with files, including C:\stuff\sorted. I want to search for all files in C:\stuff that contain a specific text, and move them to C:\stuff\sorted. So I press Alt+F7 and search. NDN has no way of excluding a directory from the search - see http://forums.muxe.com/index.php?showtopic=3236 ; so I have to just search for '*'. The problem is that some of the files that will be found can already be in C:\stuff. Another problem: in Alt+B, there is no way to sort by path, which I often find very useful. In this case, all files in C:\stuff\sorted, would be sorted at the beginning of the find panel list, and I could select only the other files. So my only choice* is to select all files, and move them to C:\stuff\sorted. The problem here is that as soon as NDN tries to move into C:\stuff\sorted one of the files in the find panel that's already in C:\stuff\sorted, it will stop the entire moving process. So two suggestions here: 1. is it possible to add "Path" to the Alt+B sort menu? 2. If a file from a list of selected files can't be moved, for whatever reason, NDN should display the "Overwrite" pop-up, with options to move elsewhere/rename etc. * - there would actually be a workaround - unselect files matching "*sorted*". However, in my test, I found that this unselected random files.

How to reproduce: 1. Have file c:\1\a.txt and c:\2\a.txt 2. Go in one panel to c:\1 and in the other panel to c:\2 3. From the C:\2 panel, move a.txt to the C:\1 panel. NDN will ask what to do about the file existing alread. 4. Choose to Rename, but don't change the filename, just press Enter. NDN will prompt again. This time press Escape. 5. In C:\2, try to delete a.txt. NDN will display a dialog that the file is in use by [nothing]. What uses the file is actually NDN.

IMO I'd like the cursor to select among buttons, once the user switches to the group of buttons with (Shift+)TAB from the edit line. After some more though, I definitely would want that. Imagine the File Find dialog. Focus on the "Text to find" edit line. Now up arrow will go to the field above (File Mask), but down arrow will not go to the field below. Another use pattern is when the user wants to move the cursor to the beginning of the edit line. Most of the time, my fingers are over the arrow keys, and on some laptops, the keyboard layout is so annoying that I avoid using the Home key whenever I can (on the ASUS EEE you have to press Fn+left arrow to get Home). So if the cursor is on one of the first few characters in the edit line, I prefer to keep the left arrow pressed until it reaches the beginning of the line (instead of pressing Home). The problem is that in the new approach. I can't just keep left arrow pressed, because after the cursor reaches column 1 in the edit line, it will go to the previous field. This also contradicts standard usage in browsers and prety much any operating system / UI I've seen :)