Pin napisał/a:Czy trudnym by było dodać aktualizację "KB FREE" w czasie kopiowania, powiedzmy co 5 skopiowany plik? Chodzi o to, by nie robić tego co chwile co w momencie kopiowania małych plików mogłoby spowodować bezsensowne straty czasu?
To chyba nie spowoduje dużej straty czasu, zobaczę.
Czy istnieje dodania opcji np. takiej, jak w TC -> po naciśnięciu spacji na katalogu otrzymujemy ilość danych zapisanych w katalogu? Niejednokrotnie kopiując większą ilość danych muszę sprawdzać odpalając CAR:MENU by sprawdzić, ile danych siedzi w katalogu/podkatalogach i na tej podstawie wiem, czy mi się coś zmieści na dysk docelowy, czy nie.
No to już nie jest takie trywialne, bo oznacza rekursywny skan katalogu. Pomyślę.
... no i kiedy kolorki pod VBXE ;)
Wszystko w swoim czasie :P
flashjazzcat napisał/a:No defense required: the main source of surprise was merely that S_VBXE doesn't fill a column noticeably faster than RC_GR8. I'd assume the software mode to be more CPU-intensive, but perhaps this is merely a testament to how staggeringly efficient the soft-driver is. :)
In fact, the screen redraws are nearly 2,5 times faster with S_VBXE than with RC_GR8.
Really - let's not feign ingenuousness: the value wasn't picked from a hat. 256 is the extent of 6502 indexed addressing.
Let's assume that "256" looks vaguely familiar and I can imagine where it was picked from :P The question was different: if already such a number of files per directory is to be handled, why not one more? There is no such limit in SpartaDOS, so why the user has to keep a cautious eye on not copying certain numberof files to a directory, especially if a much greater number is allowed? And if he does copy a 257th file, what then?
A file manager's purpose is to facilitate maintaining of the file system. Large directories are most difficult to handle, yet I have to deprive an user of this assistance just to amuse him with sorted directories? Well, I don't think so.
If a complete directory isn't held in RAM, obviously portions of same are shuffled in when they come into view. But one would assume all twenty visible names are held in RAM while they're painted on the screen.
So let's assume that. But this is a scroll, so one place must be filled with new entry. This involves reading it from the disk - and not necessarily the one, which physically is immediately following the last displayed entry - then formatting it, then displaying. So, it of course will always consume more CPU time than simple cursor movement, without a scroll.
KMK
? HEX$(6670358)
