remark field in transfer queue sometimes inaccurate

Present on at least build 3815-3817. Don't think it was present before that.

1. Queue a number of folders from multiple sources (for download).
2. Enable quick schedule (schedule at) to start some time in the future.
3. Minimize the session to tray.

When returning some time after the scheduled task has started (some folders finished some left) and maximizing the session I observe that the remark field for all queue items is identical despite several different sources still in the queue. This seems to be display related only as the physical queue file is fine.

Have not had any luck reproducing the behavior any other way.

The next time it happens can you try moving your mouse over the remark field and let me know if it corrects itself.

I think that maybe that area of the control isn't redrawing correctly after being restored from the tray, though it should automatically redraw when the control is resized.

Also can you please send me a screenshot showing the layout of the main interface you're using in FlashFXP just in case its specific to your particular layout.

Just the basic fxp layout I think... http://prntscr.com/6i67jz

I think I recall doing a mouse over and even hitting edit to see if it would redraw without success but I will play around again next time it happens and also try adjusting the field size etc. This most likely won't be until the weekend sometime as this is when I usually perform these quick schedule tasks.

In regard to redrawing there are a couple of other minor things I have noticed recently as well. Nothing disruptive but worth mentioning while on the subject.
1. In the queue window sometimes I notice that there are items (files only) still listed that have in fact already transferred (local download), I have to mouse over those items in the queue for it remove them. IIRC it redraws properly anytime their is a failure and any time a queued folder is processed. I have noticed this both when flashfxp has been in the system tray and when it has not (though also not the active application). However I don't think it occurs all the time, have been trying to keep a closer eye on it to figure out the particular circumstances.
2. Marked list redrawing is not synced between a Server File Search dialog and a remote listing. If I mark an item in one using space bar, I have to mouse over that particular item in the other listing before it is redrawn (bolded). Does not matter if the item is visible on the screen in the other area or not. Remote>Remote, Remote>Local, Queue>*, etc all seem to sync redrawing perfectly.

I try to manipulate the Queue ListView to prevent excessive drawing, even though the ListView is virtual which helps improve performance a lot it doesn't do enough in my opinion, so when inserting and deleting items I try to delay or batch the updates whenever possible, its amazing how much difference it makes to reduce CPU usage. While I haven't touched this code in quite time, there have been quite a few indirect changes that may have some impact on it.

2) I reproduced the marked list update issue on the server file search dialog, it was missing an invalidate to refresh the main window listviews. I have corrected the issue for the next update. Thank you.

I forgot to ask when you're downloading files is it from FTP, FTPS or SFTP?

FTPS. I have not noticed these things happening with SFTP but that isn't to say it is not affected just that I have not paid enough attention to notice (and of course I don't perform quite the same tasks).

Have not had much time to watch this more closely yet unfortunately. However in regards to 1) I did notice that in fact if a queue folder expands and contains a sub-folder with only one item inside then it will often not update that queue entry when it enters/expands the sub-folder.

In the example below File1 and File2 transfer then flashfxp expands SubFolder1 which contains only a single file SubFile1. This file begins transferring but the queue item is not redrawn and remains RootFolder1\SubFolder1\. I watched this occur repeatedly in an active session, but it seemed to stop when a failed item remained at the top of the queue. May have just been a coincidence but it did not happen again in the active transfer queue after that point.

#Initial queue
RootFolder1\
RootFolder2\

#Expanded queue
RootFolder1\File1
RootFolder1\File2
RootFolder1\SubFolder1\
RootFolder1\FileX
RootFolder2\

Have not had much time to watch this more closely yet unfortunately. However in regards to 1) I did notice that in fact if a queue folder expands and contains a sub-folder with only one item inside then it will often not update that queue entry when it enters/expands the sub-folder.

I was able to reproduce this issue and it appears that after a expand folder the visual display is not redrawn, its flagged as needing an update but does not redraw the list on its own during the file transfer.

I will get this fixed in the next release, thank you.

Following up as the initial issue discussed still exists in the latest build. Was finally able to see it happen again and gather a little more information...

A more detailed reproduction method...

1. Connect to SITE1 and queue several folders (eg data1 data2 data3 tmpdata)
2. Repeat step 1 for SITE2 and SITE3 (queuing folders with the same names, to same local destination)

#pseudo queue
/data1/ E:\localsync\data1\ 0 Download from SITE1
/data2/ E:\localsync\data2\ 0 Download from SITE1
/data3/ E:\localsync\data3\ 0 Download from SITE1
/tmpdata/ E:\localsync\tmpdata\ 0 Download from SITE1
/data1/ E:\localsync\data1\ 0 Download from SITE2
/data2/ E:\localsync\data2\ 0 Download from SITE2
/data3/ E:\localsync\data3\ 0 Download from SITE2
/tmpdata/ E:\localsync\tmpdata\ 0 Download from SITE2
/data1/ E:\localsync\data1\ 0 Download from SITE3
/data2/ E:\localsync\data2\ 0 Download from SITE3
/data3/ E:\localsync\data3\ 0 Download from SITE3
/tmpdata/ E:\localsync\tmpdata\ 0 Download from SITE3

3. Mark 'tmpdata' as failed for SITE2 and SITE3
4. Create a quick schedule (schedule at) to start at a later date (may not be necessary but it is the only time I've noticed this issue)
5. Let the schedule start and allow the queue to fully transfer. The left over queue will now be as follows.

/tmpdata/ E:\localsync\tmpdata\ 0 Download from SITE1
/tmpdata/ E:\localsync\tmpdata\ 0 Download from SITE1

Note that all entries state 'Download from SITE1'.

Using right-click>edit on any/all of the entries also shows them as identical. Going into the restore queue dialog, hit display all, and selecting the relevant queue shows the same incorrect information. In fact while digging into this I had another session running and viewing that save queue (within the troubled session) also showed all the remark fields as 'Download from SITE1' even though SITE1 was not used at all in the other active session and that session was displaying correctly itself.

Again viewing the queue files in a text editor confirms they are physically correct. When I reset the items and hit transfer it connects to the correct source. Upon expanding the queued folder all sub items added to the queue by flashfxp also have an incorrect remark field. The physical queue file is updated correctly.

Thank you for the update on this issue.

I will test using the method you outlined above and see if I can reproduce it.

Based on the new information you provided I have a few new ideas as well.

I am still testing my code changes to determine if the problem is completely resolved.

Its somewhat difficult because even with your in-depth method above I regret that I cannot reproduce it.

However after many days of reviewing code and testing and breaking things I discovered two issues.

The first issue might explain the problem where-by the cache is seeded with the wrong value causing future lookups to be wrong.

Basically I use an intermediate cache for fast lookups of the host names of queue items, the internals works by passing the string variables by reference and when the cache lookup is called it assumes the site name variable is a empty string, which is then set directly from either the cache or a callback that performs the lookup via a hash table. Under some conditions the site name variable being passed was not empty and contained the wrong site name, perhaps from a previous lookup, and rather than doing the proper lookup the pre-existing wrong value used and stored in the cache.

The second issue I found is unrelated to the remark field issue, but if you try to transfer a queue and the sites for the queue no longer exist in the site manager (i.e. you deleted them) then FlashFXP might get stuck in an infinite loop and lock up.