Listing synchronise on command completion

When I perform various remote commands on FTP servers (STOR, RNTO, DELE, etc) the client (any client) has total distrust in the server that it did what it was told, and requests a whole new listing.

For example, RNFR/RNTO doesn't just alter the listbox row, and DELE doesn't just remove the listbox row. The whole remote listing is torn down and rebuilt from scratch even when you know precisely what you asked it to do, and which files were affected.

RNFR/RNTO does at least roughly, vaguely try to scroll back down to where I was, but it's still irritating to try to rename several files, making Windows Explorer honestly far, far more efficient as an FTP client for such tasks (in-place rename and delete just like your hard drive). DELE fails miserably and scrolls me back up the top, which is a pain if I'm trying to weed out older files -- after every delete, I've lost my place.

Can't the client resynchronise the listing, iif the window is sorted by name/reverse name? That is:

1. LIST -> array in memory
2. Sort array by name/reverse name as per the window
3. Compare each row in window to the array, to detect new/changed/removed files
4. Tweak listbox accordingly to array

This could be flicker free, very fast and minimally disruptive. For sorting by date or size, it might be harder? But if if even just works for sorted by name, that would be a fantastic improvement.

I'm not entirely sure what the goal is of doing it this way.

If you mean that we simply didn't refresh after those commands and simply removed or updated that single entry..

We probably could get away with it for a file delete.. for rename the ftp server may apply it's own naming convention to the filename after the fact. some ftp servers enforce capitalization and the only way to know the exact new name is to refresh.

For uploads, we wouldn't know the exact file size on ASCII files (PC to non-PC ftp servers), as well as the server date/time and owner/group. We could guess or leave that info blank until a refresh but the listing wont be as accurate.

No, I mean, call LIST as normal, and then calculate what changes need to be made to the remote directory listing listbox and only change the affected rows. For example, if the listbox reads:

apple
banana
pear

And LIST returns

apple
banana
grape
pear

Then, comparing rows:

apple <> apple
banana <> banana
pear <> grape

will reveal that the listbox needs a row "grape" inserting at offset 2, since grape < pear: the file grape must be new.

Right now, you're tearing down the whole remote file list and generating a new one, which loses your scroll position, selection, and flickers horribly.

When you're in Explorer, you can rename and delete items without affecting any others: the idea is to replicate this visual and focus stability. For example, in FlashFXP's local view, delete a local file. The listbox does flicker, but the scroll position is not lost. In the remote view, you lose your place completely, which for large folders is quite irritating. Trying to rename even a handful of files (e.g. foo1, foo2, foo3) means scrolling all the way down to the next one each time, or typing out the name.

This could be useful, but only for the sake of not loosing your place in the list when performing such changes. I'm sure flashfxp could easily remember where you were for DELE as it does for RNFR/RNTO, without needing to perform and interpret a diff comparison.

'diff' is what they call it when files (or strings) are compared to find and point out the differences. Such functions can be used to produce patch files that are capable of applying the modifications to a file to make it like another.

As for rename and deletes FlashFXP will remember its location. Though not the same was as explorer, we prefer to re-sort the list. However there's a catch 22 in that situation for deletes. when the item is deleted we no longer have a way of finding the location to restore the scroll position. Which apparently wasn't obvious when I coded it. I bet I can come up with another fix for that though.

It's really just a matter of saving the view position and restoring, it doesn't really matter if we completely rebuild the list or not.

Well, the way you put it, it can't work for rename either. If you rename a file, how can you find it again? You could look for the name you just put in, but what if the server didn't call it that? Though that's another problem with the protocol itself not being trustworthy.

Worse, if you do re-sort and scroll down to the new name, how can I find another similarly-named file to rename? I've lost my place.

Explorer's refusal to re-sort, and leaving items in-place after rename, does in fact make for the easiest-to-use way to manage files. Explorer isn't fighting me every step of the way. (Except XP ... XP broke this all horribly; I use 2000.)

FlashFXP doesn't appear to even scroll back reliably even after rename -- it stopped working for me. The idea of doing the list processing in the background and *updating* the list instead of tearing it down is that it's never cleared, never rebuilt, and you get proper visual stability. There will be edge cases where extra added/removed files (say, from someone/something else) may upset the scroll position depending on how the control is written.

We'll take these changes into consideration for future versions of FlashFXP.

Actually, that's a great suggestion!
But I'm not sure you completely understood it, bigstar.

For example, a file rename...

The way it works now:
- The rename command is sent.
- The file list is cleared.
- The list command is sent.
- The file list is populated.
- The renamed file is selected (while not maintaining the scroll position of the list).

What you see is: The list disappears, and then reappears.

The proposal:
- The rename command is sent.
- The file list is not yet cleared.
- The list command is sent.
- The file list is cleared (without flicker) and populated.
- The file list is scrolled to the previous position.
- The renamed file is selected.

What you see is: The name just changes, no flicker, no position loss. Like magic

This should not be really difficult to do, while it will greatly improve user experience.
I'd really like to see this in v4.0.