dandv

Suppose you Alt+F7 for something and get several files in the Find VFS. If you move some of those files to some directory, they will be marked as hidden in NDN (in DNOSP, they disappear from the Find Results). This is perhaps better than the files simply vanishing but maybe NDN should update the path information for these files, so that you're still able to view them, change attributes, copy them somewhere else again etc. Now you can't do anything to those files, once they are moved. Hope this helps, Dan Dascalescu

Congratulations and thanks for NDNWin32 2.14.9501! In the Processes panel, Alt+B brings up the sorting options specific to archive panels: Packed size, Ratio Some processes are detected as having <No_Path> although they do have a path: winlogon.exe, smss.exe. These processes also get sorted first if you sort by Name. Their size and date+time are not detected (they default to 0 and 1.01.1980) Parent PID doesn't work in Win2000 (it's always 0). Occupied memory would be more useful perhaps. Hope that helps, Dan Dascalescu

In a directory with a shitload of files (try 10,000+), position the cursor on the 10th file. Very rapidly, perform steps 1 and 2: 1. Press and release Ctrl+R (re-read the directory) and imediately... 2. Press the up arrow (while the big fat directory is still being read) 3. What would you expect to happen? Well, instead of moving the cursor over the file above the current one, NDN will also open the file in the Viewer. The explanation for 3. is that in DNOSP, if you hold Ctrl, press UpArrow or DnArrow, then release Ctrl, DNOSP will launch the viewer for that file. This behavior has disappeared in NDN but apparently this strange condition triggers it again. PS: in the editor, Ctrl+K [ works for me (uppercases the selected block) NDNW32 9501/ENG, Win2KSP4 English

The total number of files displayed on the pane; divider (if Totals is checked in Panel Options (Alt+S)) does not have the digits separated by the thousands separator. The same happens with the total number of SELECTED files (press '*' in a directory with more than 999 files). Hope this helps, Dan Dascalescu

A Pascal unit for viewing HTML files is already available from the CONNECT (IBM Handshaker) file manager at http://www.orlov.wapil.com/connect/ Full sources are availabe in the Download section.

1. Press Alt+Q, then directly Shift+UpArrow 2. Notice how 3 lines are highlighted instead of one. And two typos: 1. Panel Options (Alt+S) -> Attribs on sepErator (correct: sepArator) 2. In the file overwrite confirmation dialog: remove the $03 character before 'File'. Hope this helps, Dan Dascalescu

1. Download http://home.arcor.de/stasis/ViewNonWrapped...nUntilBlock.txt (notice the special size - 65537 bytes. If the file is even 1-byte smaller, the bug won't reproduce. 2. View the file in NDN in UNwrapped mode. The wrapping indicator in the status line of the viewer must be <=> 3. Press PageDown several times, until you block at a line saying "The DB2 UDB database has also been designed to [...]". Notice that this is not the end of the file (press Ctrl+PageDown or search for "DHTML"). Hope that helps, Dan Dascalescu

Hi tmp, Long time ago when I used DNOSP in Win98SE, I also preferred to keep it in full-screen text mode. But after a while, I realized that I needed all sorts of information from the Win98 screen (system tray indications from various programs, such as new mail or new message; small floating windows such as Flashget's progress window etc.). This is how I decided that I would better use DNOSP in window mode. Regardless of your resolution, you can resize the NDN window (check the Font settings) so that it occupies almost the entire screen. This way, you'll also get your usual refresh rate and see the system tray and so on. One small other thing: if you are in a deep directory, NDN will show it as C:\SomeDir\...\LastDir, but in the title bar you will see the full path! Try window mode :-), Dan

This is a rather weird buffering issue: 1. View the ah_news.txt file from NDN. It should be over 72k long. 2. Search for 'SCREEN/'. 3. Search again (Ctrl+L). The first two lines from the viewer should be [-] Combine: error detection when starting on file > .d01 (Garl) [N] SCREEN/VIDEOMODES 4. Notice that in addition to highlighting "SCREEN/", NDN also highlights 7 blank spaces at the end of the previous line, after '[N]'! I tried to narrow down the conditions to reproduce this bug and I found that it doesn't happen if the file is less than 65537 bytes long. CR/LF separation type or screen resolution have no influence. OK, this bug might not be that simple to fix, so how about fixing some minor annoyances: 1. 4-year digit on ^Q,D in the SmartPad! 2. Complete file timestamps on Alt+E (not just last modification time) in NDNW32; and 1-char-longer edit fields for the time and date 3. Ctrl+Break to return to NDN after launching Windows applications 4. Clean UserScreen after executing console applications (it's still messed up in 80x43 in NDN 2.14.8486 under Win2K, try 2 'dir's in an empty directory right after starting NDN)

Is there such an equivalent? It would allow the user to launch a [] entry from dn.ext. Dan

I remember there was some talk about the keypad and NumLock, but on my configuration (WinXP English and NDNW32 2.14.7374), Alt+PgX will activate the history if NumLock is OFF. If NumLock is on, you'll enter an ASCII character like Alt+065 for 'A'.

1. Search for something in the phone book so that you get at least one result. 2. Dupe the result. 3. Go to the "parent" of the search results enter the current folder again, and watch NDN crash. 4. If NDN doesn't crash, start with a blank Phone Book, create one group and one name. 5. Even if NDN won't crash, you'll have some strange entries there, like two '..' entries in the folder with the duplicated search result. Hope this helps, Dan 'The Bugfinder' Dascalescu

Try deleting the file q.mac from the Edit History (Alt+PgUp) then reopening it. You should see the highlight now.

1. Create a file with the following contents bugg 1 bug 2 2. View the file and search for 'g', Whole words. 3. Notice that NDN finds the g in 'bugg'. That is because the character before 'g' was another g. NDN will also find 'gg' in 'buggg 3'. This doesn't happen in the editor but happens in DNOSP's viewer :-> Hope this helps, Dan Dascalescu PS: is this code in fviewer.pas to blame, or is it a problem related to the Boyer-Moore table? if WholeWords and not (((BufPos = 1) or (Char(Buf^[BufPos-2+StPos]) in BreakChars)) and (Char(Buf^[BufPos+Length(What)-1+StPos]) in BreakChars)) then

When I launch notepad.exe from NDNW32 build 7473, I can't get back to NDN, not even after Ctrl+C or Ctrl+Break! I have to close Notepad. Alternatively, I have to run "start notepad". I clearly remember that I had reported this bug and it was fixed in a previous release, I think 6446 (6873 still has the bug). Maybe there is a setting somewhere? Configuration -> Command line seems related, but what does it do? Hope this helps, Dan

How about a totally different and quite powerful approach, also adopted by DNOSP: Don't check for anything, just exec() the executable, but interrupt it if the user presses Ctrl+Break in NDN! DNOSP does that and it works perfectly, although they also have the notepad.exe myfile.txt bug.

I also encountered the E:\NDN\SOURCE\views.pas(1289) error in NDN 2.14.7374 but I haven't reported it because I can't reproduce it for a small enough file. Here's the mail I was going to send to AH: (──NDN── 14.08.04 20:04:20 ════════════════════────────────────) I'm sorry that this bug report doesn't follow the neat and utterly precise style of my previous bug reports, but I frankly didn't have the incentive to spend more than one hour trying to pin it down. The idea is that for ONLY a given file, an 155_455_436-byte MP3, viewed in Hex or Dump mode, going (F5) in the to an address around $4EF0000 crashes NDN. I tried with various other, bigger and smaller, files, but I can't reproduce it. The smallest address which causes the crash in Dump mode is $4ea65bf, but in Hex mode you can still F5 there. I hope the source code will tell you more... Alternatively, I can send you the file in 25-Mb archives over a public FTP server, or if you have an FTP server, I can upload it there at roughly 40Kb/s. I have uploaded the NDN.ERR file to http://www.rootshell.be/~dandv/ndn_err.txt

1. Make a file with the following contents: aaaa 2. Search forward, not whole words, for 'a'. Notice NDN gets stuck at the first match. It would only advance if there existed a following line, such as aaaa b 3. Now create the file a a a a 4. Search forward for 'a'. Notice NDN scrolls up the view unnecessarily. 5. Additionally notice that in none of the cases will you get a "Search string not found" message. 6. Now that the search highlights the 4th 'a', search Backward for 'a'. Notice NDN only finds the 3rd 'a' and gets stuck there. 7. Scroll one line up, so that you see 3 a-s. Ctrl+L or Shift+F7. NDN will find the NEXT 'a' FORWARD! 8. Press F7 and OK to search Backward and NDN will correctly find the first 2 a-s. None of these bugs appears in DNOSP.

In any of the Hex, Dump or ASM modes of the FViewer, the Goto Address editbox only allows 8 characters, which is wrong if the user wants to enter $8_digits, 8digits_h or 0x8digits. It should allow at most 10 characters. Hope this helps, Dan Dascalescu

Hi AH, If I press F2 in a directory where I don't have an NDN.MN2 file, I expect NDN use the global menu without complains. But, NDN first complains that it could not find the local menu file, then it displays the global menu. Is there an option to disable that? I only found an Interface Setup option to "Find NDN.MNU in upper dir", so if you decide to implement this option, this would be a good placement. Alternatively, the complaint could be silenced :-) Best regards, Dan

1. Create a file with the following contents: word1 word2 (no trailing end of line) 2. View the file in non-wrapped mode (the status bar indicator should be <=>) 3. Notice that word2 is wrapped to the second line! Hope this helps, Dan Dascalescu

...because NDN switches back to its interface when you *press* Alt. It should only switch back when Alt is released, thus giving a chance to Shift+Alt+Ins to be caught. Hope this helps, Dan Dascalescu

Garl, if that was a suggestion, then the problem is the same: NDN switches out of User Screen mode whenever you PRESS a key (port[$60] < $80), not when you RELEASE it. There's nothing wrong with the Shift+Alt+Insert combination. NDN should simply switch out of the User Screen when there is a key release, as DNOSP does. This will enable Shift+Alt+Inser to enter its own state, which is exited by Enter or ESC.

In NDN 2.14.7374 W32 on Windows XP SP1, under video mode 80x40: 0. Start NDN, notice the blank output screen, then: 1. Execute "for /L %i in (1,1,52) do echo %i" or, a command that causes the screen to scroll (e.g. "dir c:\ /s" 2. Execute "ver". 3. Notice that the results of "ver" appear at the top of the screen. A fresh NDN start is important. Otherwise, the bug is not always reproduced. Can someone confirm this behavior? Hope this helps, Dan Dascalescu

AH: What if instead of Alt+F5 you press ESC and "ESC for user screen" is enabled? Garl: Ctrl+O does not show the first line of the screen.