Queue editor is broken when editing multiple queue items in v4.x

When editing the target path for multiple selected items in the transfer queue, the 'Name' is changed to 'Multiple Selected' instead of the original file/folder names.

It is not a matter of display only, it literally thinks the all source files/directories are now called 'Multiple selected'. As a result of this, it tries to cwd to 'Multiple selected' for each of the items and hence fails the transfer since there is no directory called 'multiple selected'.

It does not happen when a single item is edited, only with multiple selected.


To replicate:

Queue up multiple files/directories
Select more than 1 items in the queue and go to edit queue (Ctrl + E)
Change either source or target path and press ok
The selected items are now renamed to 'multiple items' instead of the original filenames/directories.


Using FlashFXP v4.0.0 (Build 1540) Portable on Windows 7 Professional (English).
This was not an issue in FlashFXP v3.6.0 (build 1240) Portable.
The bug existed in the previous build of v4 as well.

This bug is possibly related to ticket #456

Does this bug occur in build 1545?

I am having some difficulty reproducing this bug so either its been fixed or I'm not doing the same steps as you to reproduce it.

yes, i just did a clean install of the portable version (v4.0.0 build 1546) and the problem still occurs.

Only thing transferred from the previous install was sites.dat

Screenshot included below.

So I thought I fixed this problem.. Wait.. I did fix it.. How could this be?

It took me awhile and its one for the record books.. perhaps even the hall of shame..

So here's what happened..

Before releasing build 1546 I had several near releases, meaning the files were uploaded and ready to go the moment my testing was completed, during this process I found some issues and some more issues, needless to say there were probably 3 versions of 1546 ready for release.

These files are kept on a server ready for release, however someone tried to download file before it was officially released by guessing the name, its not too difficult to do, since they're all using the same syntax and downloaded one of the early builds of 1546.

Typically this would be no big deal except I use a pull style CDN and my CDN cached this buggy build of 1546, when I finally made 1546 official the pull server had the correct builds, but the CDN was pushing out the cached content (the old buggy builds)

Needless to say this hosed the 1546 release for everyone who tried to download the update. I have cleared the CDN cache but its probably too little too late.

This also explains why you experienced this issue in build 1546.

I had fixed this issue in 1546.

In the future I will need to keep these pre-release builds in another folder to prevent this type of situation from occurring.

I learned my lesson ouch!

So I guess this means maybe I'll be releasing 1547 tomorrow..

You can re-download 1546 to confirm the issue is resolved by testing the intended release.

hehe technology can be a b*tch sometimes

i can confirm the bug is fixed in the newest build (build 1548).