dandv

In the editor, could Alt+arrows act like Ctrl+K,I/Ctrl+K,U ?

You're right, if I run notepad.EXE it will work as expected, but why do I have to type ".exe"? I think you check for .EXE being at the end of the command, which is wrong if the command is followed by something, such as "notepad.exe myfile.txt" (try this :-). Anyway, the user should not be forced to append ".exe" :) That might mean they don't do much ;-)

1. Create a target file, say target.ext 2. Find a big enough file to allow you some time while it gets copied. 3. Copy the big file over target.ext and at the Confirm prompt choose Append. 4. While the big file is appended to the target file, stop the operation. 5. Notice that the target file has been deleted!!! This is potentially disastruous. What NDN should do whe the user interrupts the appending process is stop appending and truncate target.ext to its original size. BTW, this is also a bug in DNOSP, but ssshhh, don't tell them :-) Hope this helps, Dan Dascalescu

I have drive Z: mapped to a network path on my laptop. Today when I started NDN, I had to wait about 15 seconds before NDN showed the file manager panel. I had no other windows etc. but the laptop was not connected to the network. I repeated the experiment 4 times, with the same results. Then, I connected the laptop, accesses drive Z using Explorer, and started NDN again. This time NDN started instantly. I think this problem might be related to NDN attempting to retrieve the current directory from all drives at startup, including removable drives. In DNOSP, there is a setting to disable that: Configuration -> Interface -> Drive selection menu information type -> Show current directory for network drives. Can NDN be made to NOT query network/removable drives at all at startup? (I haven't found such an option in NDN) Thanks, Dan

Here's a bug discovered in a funny way: I went to http://ndn.muxe.com/archives/ instead of just http://ndn.muxe.com. The Download link in http://ndn.muxe.com/archives/ points to http://ndn.muxe.com/archives/dwl.php , which doesn't exist. The correct URL is http://ndn.muxe.com/dwl.php . I suppose http://ndn.muxe.com/archives/ somehow serves the index.html in http://ndn.muxe.com but without setting all links correctly. BTW, the text beneath the screenshot still reads "Latest version : 2.14 Build 5661"

I also felt the need for some marker indicating another page of combo boxes. After I noticed that they were between angle brackets, , that sufficed. But I guess it's not very intuitive to just have the different brackets :-) PS: build 6873? Right now, http://ndn.muxe.com/archives/w32.rar is build 6446 as of July 15. Where can I get the truly latest build? Or Elfy, you're not talking about the W32 version?

Searching in ANY editor or viewer for a single * with Regexes enabled will crash NDN. I didn't paste the error box because the Line was random anyway :-) Hope this helps, Dan Dascalescu

Thanks for the insight, Garl! ;-) If you are interested in some really complex regular expressions, you might want to check out my Proxmail project, which makes heavy use of regular expressions. See link in the sig :-) Dan

Hi AH, Any of the * and + quantifiers not preceded by something to quantify will produce a crash. Examples: * *aaa aaa(*B) + +aaa aaa(+B) Hope that helps, Dan

The output window (Ctrl+O) should be scrolled up one line after executing an external command, in case the executed command didn't end its output with a newline. For example, a "begin write('a'#13#10'b')end." program executed from the output window will apparently display only 'a'. Hope this helps, Dan Dascalescu

1. In an Editor, type 'a', followed by 248 'x's, then 'b'. The 'b' will be on column 250. 2. Search, with Regular Expressions enabled, for a.*b NDN will find the text. 3. Add an x among the x-es. 'b' will be on column 251. 4. Search again for a.*b . NDN will delete the entire string! 5. To solve the mystery, add another 'x' and search again. NDN will say "1 replaces made" (but you just Searched (F7)). 6. Add at least another 'x', search again and watch NDN crash. Hope this helps, Dan Dascalescu

Hi AH, How did your exam go? :-) Here's a new bug for you: 1. Make sure you have an external viewer set for an extension, say .jpg. 2. Enter a directory which contains, in itself or in its subdirectories, .jpg's. 3. Find (Alt+F7) or Branch (Ctrl+H) to get a list of .jpg files. 4. Enter the '..' directory. Notice you will correctly be returned to your folder. 5. If between steps 3 and 4 you view a .jpg, step 4 will return you to the root folder of the drive. If instead of a Find File or Branch, you do the same thing with an archive, you might get returned to C:\ instead of the root folder of the same drive. Hope this helps, Dan Dascalescu

This is an ancient bug (still in DNOSP April 26): 1. Change the archiver name for, say, RAR, to something invalid. 2. Enter a RAR archive and view a file (F3). 3. Notice NDN still called your old RAR handler. Hope this helps, Dan Dascalescu

Good luck on your exam! Regarding Shift+Enter and menus: any change of getting Alt+Home launching the Alt+Enter menu like in DNOSP? Dan

Am I missign something or NDN resets the archiver configuration to the default if invoking the archiver returns a non-zero exit code? I was trying to setup Infozip's UNZIP.EXE instead of PKUNZIP and because UNZIP doesn't support list chars, it returned an error. After that, I saw all my settings for ZIP reset to the defaults (e.g. PKUNZIP.EXE as the archiver). The list char is another issue: if it is missing, NDN should call the archiver with the selected filename(s) appended one after another at the command line, and NOT all of them between quotes. Besides quoting them, NDN outputs the first filename TWICE! Hope this helps, Dan Dascalescu

... appears to crash NDN W32 2.14 build 6446, after it attempts to launch something according to the menu entry in ndn.ext). What it attempts to launch seems to be a pointer to something (four 'funny' characters). For example, pressing Shift+Enter on a .txt file in a .RAR or .ZIP archive will prompt the user to convert to/from UUE (the '*' menu entry), after which NDN will crash with the message below: +------------- Fatal Error --------------+ ¦ ¦ ¦ Exception 0D8h at address 00440630 ¦ ¦ in E:\NDN\SOURCE\dnexec.pas ¦ ¦ Line 926 ¦ ¦ Access violation ¦ ¦ Please report to author: ¦ ¦ email: ho1459@bnhof.de ¦ ¦ ¦ +------[ Press a key to exit now ]-------+ (which reminds me about the bug of PARTIALLY converting SOME ASCII chars higher than 128 to some poor equivalents: When NDN crashed, I used the console window's Mark command to select the red crash window and copy it in the clipboard. In DNOSP, the window's contents and borders pasted perfectly: the vertical double line (chr(186)) was preserved. In NDN, it was converted to chr(221), a character which when copied into the clipboard will carry with it the conversion to yet another character. Hope this helps, Dan Dascalescu

Hi AH! Since you had an easy last week with not many bug reports, I thought I could bring you up to speed with this little one :-) 1. Edit a file 2. Search for a string until you get the "Search string not found" message 3. Press Ctrl+F5 to move the dialog box around. 4. Notice you can only move the window vertically! The left/right arrows do not work! Hope this helps, Dan Dascalescu

In general, on a case-insenstitive file system such as NTFS or FAT32, when NDN needs to check if two filenames are the same, it should NOT simply compare them, but compare the lowercased (or uppercased) forms. That way, 'c:\a.a' will be detected as being the same as 'C:\a.a'. Not implementing this procedure could lead to potentially dangerous problems. Since I do not have the source code, I will let the NDN author discover and correct such incomplete checks. One example of a situation which leads to a bug is the fact that you can fool NDN in opening the same file in two windows, although Confirmations -> "Reload a file in viewer/editor" is checked: 1. Edit an existing file, let's say "c:\autoexec.bat" 2. Shift+F4 and type "C:\AUTOEXEC.BAT". 3. NDN will NOT detect that the files are the same. Hope this helps, Dan Dascalescu

Right! It's the "Confirmations -> Open new window" setting.

Congratulations for the new 6017 build! But, when I try to change directory to any network path, such as "cd 2.168.2.1\C$", I get the Fatal Error below, with a spurious line number (sorry for the "fake" characters, apparently the clipboard transformation is still there ;-) +------------- Fatal Error --------------+ ¦ ¦ ¦ Exception 0CAh at address 004f0209 ¦ ¦ in ¦ ¦ Line 13697084 ¦ ¦ Stack overflow error ¦ ¦ Please report to author: ¦ ¦ email: ho1459@bnhof.de ¦ ¦ ¦ +------[ Press a key to exit now ]-------+ Hope this helps, Dan Dascalescu

What exactly does "Show replacement" do? If "Ask" is off and I "Change all", all occurences are replaced without prompting, regardless of the state of "Show replacement". If "Ask" is on, "Change all" replaces all occurences WITH prompting, regardless of the state of "Show replacement". So there's at least one bug here, since the help claims that "You don't need to watch each replacment, turning Show Replacement off also turns Prompt on Replace off." (turning it off didn't disable prompting). BTW, maybe the "Ask" checkbox should be renames to "Prompt on Replace" for clarity and for consistency with the help. And, what does "Show replacement do"? If nothing, I would propose it displayed, highlighted, the new text instead of the old text. Hope this helps, Dan Dascalescu

1. Ctrl+F5 doesn't work in Edit windows. When you press Ctrl, the status bar entry for F5 is marked as "*FREE*". 2. The Find dialog box has conflicting shortcuts for Case ~sensitive and ~Selected text. Hope this helps, Dan Dascalescu

Yep, since they are general window-related functions, like Ctrl+F4 (close), Ctrl+Tab (switch), Alt+Z (zoom). And you also wrote in the TO-DO: "+ UserScreen (AltF5) from everywhere in NDN" Regards, Dan

1. In NDN.HGL, place the entry below: FILES *.PL MULTILINESTRING 1 END 2. Create a called file BUGHUNTER.PL with exactly the following contents: "Dan the BugHunter" } 3. If you attempted to create the file with NDN after adding the entry in NDN.HGL, you'll aready have a crash without even opening the file! (just Shift+F4, BUGHUNTER.PL, Enter). 4. If you created the file with something else, attempt to edit BUGHUNTER.PL and watch the crash :-) Hope this helps, Dan Dascalescu

Aside from the Smartpad (Alt+Q), the four digit year setting should be reflected (maybe; I hate two digit years anyway and would prefer 4 always, but just for the sake of consistentcy) in the File Attributes dialog (Alt+E on a file). In that dialog, in the Date edit box: 1. The year is always 4-digits. 2. The date separator is always '-', instead of the one from "Country support" 3. Pressing End does not put the cursor after the last character 4. If you enter 04 instead of 2004, you'll get 2052. By the way, where are the creation and last access file times? I can't see any of them, neither on NTFS, nor on FAT32. Hope this helps, Dan Dascalescu