4.3.0 b1940 Drag and drop slow (4-5 secs) and more...

Hi,

Sorry for reopening this bug report.

#When dragging a folder from a remote site (right top window) to the local browser (lower left window) #it takes a second or two before the drop shows the folder as queued.
#Right click and select 'queue' is as instantaneous as always.
#Just the drag and drop has a definite hesitation in the last build.
#
#No logs or any other information that makes it clear what exactly happens.

I was too fast with reporting that it worked.
It worked for only the short session after I upgraded from 1937 to 1940.
After a short while it stopped working at all.

For me to reproduce consistently:
1) Setup a connection to a ftp server
2) browse to desired folder

To show and feel exactly how long it takes:
3) select folder to download with left mouse button and KEEP THE BUTTON DOWN until the icon changes from pointer to the pointer with the [+] sign. For me it takes at least 4 to 5 seconds.
4) then drop to lowerleft window.
File will be queued as usual.

Extra:

Now for the weird part:
1) Setup a connection to a ftp server
2) browse to desired folder

3) select folder to download with left mouse button, drag and drop it a little further away in the same window. Say you drag and drop the folder 0.5 inch to the right.
(like an accidental drag)

After 4 to 5 secs the file will be queued for download to (in my case):
c:\Users\[username]\AppData\Local\Temp\[selected folder]\

Which is definitely not the expected behavior.

The mouse cursor wont change from normal to drag mode until the mouse is moved at least 4 pixels while the left mouse button down.

I cannot explain the behavior that you experience when dropping onto the same window, the only way to drop within the same window is by dropping onto a folder which triggers the "move operation". A drop operation anywhere else within the file list is not allowed.

What version of Windows are you using?

Would it be possible to create a short video of the problem, I am very curious to see exactly what happens.

OS: Window 7 64-bit SP1, fully patched
FlashFXP: latest available.

Video at: http://youtu.be/8PiGuY0QM9s

Please run it full screen and at 'highest quality'.
(The first run may not be as clear as a repeat )

Storyline:
*) connect to Adobe ftp server
*) drag'n'drop "coldfusion" to lowerleft window to queue
*) clicked on "edge"
*) drag'n'drop "flex" to the right
*) drag'n'drop "okyz" to lowerleft window to queue (the moment i do that the first drag'n'drop action gets completed)

Mouse gets the divider icon
*) clicked on "digitaleditions".
Still waiting for the 'okyz' folder to get queued...

*) the moment my mouse rests on the 'dpsdesktoptools' i have right clicked it and am waiting for the popup menu to appear.

Once the 'okyz' folder gets queued, the popup menu appears.

*) drag'n'drop "creativesuite" which didn't get queued (may be not done properly) but you'll notice the definate delay before the right click to queue "dreamweaver" appeared.

The weird drag'n'drop to the right doesn't queue anything anymore in the 1941 build but the delay is still there.

I hope it shows a bit how i experience it.

PS: my system is just idling while i recorded the video.
PS2: I was running 1940 with problem, updated to 1941 with auto restart and it worked for that session. Stopped 1941, started 1941 and problem is back.
PS3: disabling the firewall and antivirus software didn't make a difference.

Please try this dev build.

https://oss.azurewebsites.net/testr/dev-bu...4.3.0.1942.zip

This build removes one of the file system monitors we use for detecting drag/drops to external windows. I suspect that this delay is caused by the file system monitor.

Hi,

I can't test really objectively right now because I am running a full system security scan (virus scan/cleaning, risk analysis) so my disks get a real beating.

First impression:
The folder gets queued straight after the following.
Create temporary queue file (fqf), update FlashFXP.ini and Stats.dat

And that is almost immediately (with my current high disk i/o just after a second)

The build you gave me/us shows the pointer with [+] at mouse down and start of drag so I suspect you have indeed found the routine that hampers the performance.

[thumps up]

Can i keep this one?

How many hard drives do you have in your computer?

Are any of them external?

Does your Windows power management profile turn off the hard drives after a certain amount of time?

Do you have any network shares mapped to drive letters? if yes how many?

While fix isn't a permanent solution I do believe we are headed in the right direction.

Q: How many hard drives do you have in your computer?
A: 2 local drives

Q: Are any of them external?
A: No external ones attached (Talking about USB/Firewire disks)

Q: Does your Windows power management profile turn off the hard drives after a certain amount of time?
A: Using Balanced profile (recommended). I found in the advanced settings that it turns off the hard disk(s) after 20 mins. ( Not that they get the chance but it is configured that way ).

Q: Do you have any network shares mapped to drive letters? if yes how many?
A: Yes, 3. (1 NAS attached)

Can you please try this build. I re-enabled the code from the last build and re-worte it to skip network drives.

https://oss.azurewebsites.net/testr/dev-builds/ffxp4.3.0.1943.zip

If the problem is related to the mapped network drives then this should not have any delays.

Hi,

This build works like a charm as well.
Drap and drop show the folder [+] and is practically as fast as Ctrl-Q

(I also tried with 1940 build to confirm its still slow and that the improvement is indeed in the 1943 build and not circumstantial).

Thank you for testing the update and confirming the fix.

Future updates include this revised code.