UI problems

I have no idea how to reproduce these problem consistently but I've seen three problems from time to time and thought I'd bring them to your attention.

1) The transfer queue will occasional end up with a permanently selected item. You can click/highlight other entries but the stuck one even if selected and then unselected remains highlighted. I didn't think to test if it responds as a selected item such as mark bad, etc but visually it's wrong at least.

2) The icon bar above the directory listing with the connect, disconnect, switch local/FTP, etc icons occasionally disappears entirely and won't come back. I forget it the UI elements right under it such as the directory path, etc also disappear... Minimizing the window and restoring it doesn't bring it back which I presume it should if it was just a simple repaint problem.

3) Rarely if creating a new FlashFXP session and choosing not to restore a queue by hitting the cancel button will end up with Flash stuck and failing to respond to anything else. Windows detects it's not responsive if you attempt to close the window and you can force it closed through explorer.

1) This should be fixed in the dev build that I linked you in ref to bug #746

2) This is quite unusual, What toolbar icon set and background are you using?

I can't seem to reproduce 2 or 3 this, but will continue to investigate the issue. I have reviewed my source code repository comparing changes for the past 2-3 months looking for anything that might shed some light on either of these issues but unfortunately nothing stands out. Any idea when either of these two issues first appeared?

I think the not drawing issue first showed up quite a while ago, say 4.1.0.1649 from Sept, but it's also happened under the latest 4.2, so it isn't a brand new problem but I don't remember it ever under older releases. I'm using the classic main/navigation themes.

I'll see if I can't figure out something that I'm doing that triggers the problem.

I just opened up a Flash window and it's just the right hand side icon bar (classic themed, local dirs) missing (left can go missing other times though). The line under it with the current directory, parent up arrow, etc is still there. Resizing the Flash window or the size of the right hand side didn't make anything appear. Clicking anywhere in it did nothing, but I clicked on the left hand side local/FTP toggle and now the right hand side is just missing the Local Browser identifier. Pause and everything to the right of that is again visible. Now that the local/FTP icon is visible I can click that and the FTP connect/disconnect/cancel icons show up, toggling back to local the Local Browser id is still missing...

Changing the theme in the preferences changed the icons but the Local tag still missing.

I'll try and leave the window around in case you have any tests you want me to perform on it.

I am quite stumped on this, perhaps a screen shot or two might help shed some light.

Also do you have the following setting checked?
Main menu > View > Swap Panes

Didn't even know of the swap pains option... it's not checked and toggling it now does swap the pains, but it didn't fix anything.

Another tidbit, the 4.1 build is under XP, the latest stable 4.2 build is under Win7 on a different machine.

Please give this a try

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

1801 seems to have correct queue times (so far at least), and none of the just reported problems have re-appeared yet, but one thing that is wrong is the ordering of list items in the queue after a move to front/back. If you select A/B/C and move them to the top it's coming out B/C/A or something like that. It's not right. Also, if you highlight a few files and drag them down the list and then attempt to select a few more files holding down shift it's using the original position (before the manual drag move) and not the current position so it highlights a bunch of files you wouldn't expect. There might also be something else as once or twice I would do something and it didn't do what I expected but I wasn't paying attention well enough to figure out what the heck didn't work right. I was just doing a lot of clicking, etc trying to break things. I think it's related to the last problem of incorrectly stored start/end locations but because I hadn't moved the file but up or down one I didn't figure out the problem until I had moved things around more...

Oh, just noticed the now working estimated queue time seems to do weird things whenever it finishes a file. A 16hr queue would show 2 min or something (perhaps the time for the next file which was about 2 min) before jumping back to 16hr+. The windows status bar icon doesn't jump similarly though. Could just be it's updated less often so it's less likely to have that issue.

Another tidbit. I seem to remember being able to change the listing option (list/stat/mlsd) on the fly without having to relogin. However I think that's because I used to pick list and switch to stat and that took effect immediately. However I was just using a FTP with a site set to auto-detect and when I didn't like MLSD I changed it to stat and that didn't take effect until I relogged in. I'm guessing it remembered the auto-chosen setting and didn't care what I changed it to, but I'd think optimal behavior would be to use my new choice...

Originally Posted by Yil

but one thing that is wrong is the ordering of list items in the queue after a move to front/back. If you select A/B/C and move them to the top it's coming out B/C/A or something like that. It's not right.

If I have 4 items in the queue A/B/C/D and select A/B and I move up it does swap B with A. I have corrected this for the next build.

Now if I move A/B to the bottom the order is preserved and moving A/B back to the top is also preserved.

I was not able to detect any oddities when using the mouse to drag/drop move to re-arrange items, however from my experience I have seen via remote desktop/vnc situations where the listview control will sometimes behave differently than expected. Since the listview is a native windows control its difficult to know what specifically is effecting the behavior.

I am curious are you moving the items while the transfer queue is in progress?

Do you have windows themes enabled?

Originally Posted by Yil

Oh, just noticed the now working estimated queue time seems to do weird things whenever it finishes a file. A 16hr queue would show 2 min or something (perhaps the time for the next file which was about 2 min) before jumping back to 16hr+. The windows status bar icon doesn't jump similarly though. Could just be it's updated less often so it's less likely to have that issue.

Does the queue contain files for upload, download, or site to site?

I am noticing a rather large jump in the estimated queue duration when one transfer ends and a new one starts, during this in-between transfer period an alternative method is used to calculate the estimated queue duration and it is causing the spike. The alternative method was intended to adjust the estimate when performing queued non-file transfer operation, such as an en-queued rename or move.

Originally Posted by Yil

Another tidbit. I seem to remember being able to change the listing option (list/stat/mlsd) on the fly without having to relogin. However I think that's because I used to pick list and switch to stat and that took effect immediately. However I was just using a FTP with a site set to auto-detect and when I didn't like MLSD I changed it to stat and that didn't take effect until I relogged in. I'm guessing it remembered the auto-chosen setting and didn't care what I changed it to, but I'd think optimal behavior would be to use my new choice...

Since the structure and parse format of the LIST and MLSD command differ, changing between them while connected can cause unusual issues with some FTP servers where the result from one might not be exactly identical to the other, especially when it comes to ANSI/UTF8 filenames.

To prevent these issues we do not apply to the change until the next connection, you can however change between LIST and STAT while connected.

Hmm, the XP machine isn't themed and is just using the defaults, win7 isn't themed but I believe I've set the DPI to be higher and upped the font size so text is a little bigger.

Yea, I'm moving items while the queue is in progress. It's a slow connection so it's not changing often compared to my playing with items in it, but that's certainly a good thought about why it might be behaving oddly on me. Queue is download only and contains a mix of files and expanded directories (so I can get an estimate of transfer time).

Glad to know that tidbit about list/mlsd/stat.

Try this. Select a file say #6 and move it to the top (transfer in progress, not sure if that matters), now it's one down from the top, press the shift button and click #4 to select everything between them in the queue. The newly selected range is not #2-#4 but rather #6-#4. It's using the original position of the item before the move to top operation.

Originally Posted by Yil

Try this. Select a file say #6 and move it to the top (transfer in progress, not sure if that matters), now it's one down from the top, press the shift button and click #4 to select everything between them in the queue. The newly selected range is not #2-#4 but rather #6-#4. It's using the original position of the item before the move to top operation.

I was able to reproduce this selection oddity, it took the better part of the day to figure out a to way to work around it, but I did.

For awhile there I wasn't sure if it was a virtual listview bug or something goofy with my implementation.. the problem is that if you move an item and change the selection/focus state the visual listview doesn't keep proper sync with the data backend.

Unselecting all items and then updating the item state of the selected/focused items didn't work (it works but breaks the multi-select item selection as you've indicated above), which in my opinion is the most logical way to update the item states.

Finally I found a solution which is to empty the visual listview and then re-add them, then adjust the item selection/focus states.

I need to do some more testing to ensure these changes don't cause any side effects as well as apply these changes to both the local and remote listviews, they appear to be effected by this issue when refreshing a directory or after a compare folder content w/ hide matches.

[UPDATE]
Turns out this solution has some side effects.. Further research has revealed the problem boils down to the fact that a shift select triggers LVN_ODSTATECHANGED with the range of the items that changed. When LVN_ODSTATECHANGED is used instead of LVN_ITEMCHANGED the item focus tracking isn't properly preserved.

My new solution is to detect situations that would trigger LVN_ODSTATECHANGED and override it with my own custom item selection code eliminating the problem.

I am testing the new code on Win2000, WinXP, Win2003, Win2008 R2, Win7, and under Wine, so far everything seems to work, once I complete my tests I will post a new build.

[OFF-TOPIC]
I did discover an unexpected and unrelated bug when running FlashFXP under Wine. Starting in v4.2 we switched from the standard windows timer (WM_TIMER) to a threaded high-resolution event timer, the new threaded timer has a critical section re-entry glitch causing the timer thread to dead-lock.

Ironically this issue was undetected and went unnoticed under Windows.

This dead-lock issue might explain a couple open bug reports that I haven't been able to solve, specifically the ones related to remote editing and edit and upload not triggering an event for uploading/prompting on save.

I released a new beta build 1803 via liveupdate that should correct the item selection and the threaded timer dead-lock.