FlashFXP 4.1 RC 3 build 1632

[spudgun]

Originally Posted by bigstar

FlashFXP 4.x and up will re-try failed transfers up to the (user defined amount) and I believe this is what you're seeing. Preferences Dialogs > Transfer > Retry Failed Transfers

I do believe that the proper way to address this special folder is to add it to your skip list.
Set the mask to \[*complete*] and compare to Name of folder

The [ bracket is special in 4.x, so it must be escaped with the \

This should resolve the issue.

Thank you, that has resolved the issue :-)

[ecksteinn]

I run FFxp on a portable hdd. This installer does not properly update my alrewady installed portable version. Instead it tries to install Ffxp new on my C-Drive. The installer was downloaded via the update function of the running instance.
This worked since weeks/month. Today the auto-installation stopped working. I don't install this version else I have to fight with two versions installed on my box and copying files here and there to get it updated.

[bigstar]

Originally Posted by ecksteinn

I run FFxp on a portable hdd. This installer does not properly update my alrewady installed portable version. Instead it tries to install Ffxp new on my C-Drive. The installer was downloaded via the update function of the running instance.
This worked since weeks/month. Today the auto-installation stopped working. I don't install this version else I have to fight with two versions installed on my box and copying files here and there to get it updated.

This issue appears to occur only when upgrading from build 1631, You can download build 1632 portable edition using this link http://www.flashfxp.com/?d=252

A change in build 1631 resulted in it sending the wrong info to the update server, I rewrote this code for build 1632; unaware of this issue, I was trying to fix the crashing. The new code does not contain the flaw that existed in 1631. I tested build 1632 and it does not have this problem.

[bassiliin]

Same thing. Usually I open FlashFXP to check new versions and download via live update and always get portable intsaller as I am using portable version but today build 1632 came as regular installer.

Bug or feature?

[msg7086]

adding files to queue after starting the transfer does not update the taskbar icon percentage (the green bar)

bug or won't fix?

[bigstar]

Originally Posted by msg7086

adding files to queue after starting the transfer does not update the taskbar icon percentage (the green bar)

bug or won't fix?

It should, how many files are in the queue immediately prior to adding more?

Are you specifically adding files or folders, is it an upload, download, or site to site transfer?

[msg7086]

Originally Posted by bigstar

It should, how many files are in the queue immediately prior to adding more?

Are you specifically adding files or folders, is it an upload, download, or site to site transfer?

let me explain how i find it.

say, a single 6GB file in the queue, with 3GB already done. now resuming the queue (at 50%), add another 6GB single file into download queue. and the taskbar icon is still at the middle (~50%) but expected to be 25% right?

i just meet the problem occasionally and hasn't done many futher tests. this appears both on build1561(my pc) and build1629(my laptop)

[bigstar]

Originally Posted by msg7086

let me explain how i find it.

say, a single 6GB file in the queue, with 3GB already done. now resuming the queue (at 50%), add another 6GB single file into download queue. and the taskbar icon is still at the middle (~50%) but expected to be 25% right?

i just meet the problem occasionally and hasn't done many futher tests. this appears both on build1561(my pc) and build1629(my laptop)

The over-all queue progress percentage shown on the taskbar isn't updated in real-time, it looks like when a file is added to the queue the percentage isn't updated fast enough, it may take up to a minute or more. I will change the way the taskbar progress is updated to ensure that it's updated at least once per second when the percentage changes. Thank you

[msg7086]

Originally Posted by bigstar

The over-all queue progress percentage shown on the taskbar isn't updated in real-time, it looks like when a file is added to the queue the percentage isn't updated fast enough, it may take up to a minute or more. I will change the way the taskbar progress is updated to ensure that it's updated at least once per second when the percentage changes. Thank you

i would suggest that updating the progress when a great change on the queue happened. say adding or removing a file that is larger than 1% of whole queue size, etc.

Originally Posted by bigstar

I happen to have a machine running windows server 2008r2 that I access via remote desktop. I attempted to reproduce this lockup but was unsuccessful.

It could be caused by a specific setting set via the remote desktop connection, I tested every possible combination that I could think of, all the color depths, performance settings, etc.

Was FlashFXP idle or busy when you connected to the remote desktop? You might want to test again with 1631 and see if you still have the same issue.

i just comfirmed that switching the option under win7 laptop with aero enabled would cause the window halt just the same way. flashfxp eat whole single cpu resource.
i'm downloading the new rc build and will let you know after further test.



-=EDIT=-

build 1632 is no good. still halt. i attached flashfxp.ini here with personal infomation wiped. hope it helps

[ecksteinn]

Thanks bigstar, the portable update setup worked!

[msg7086]

BTW, the 'suspend/hibernate after queue completed' function could display an extra prompt to choose if the function would be reset to 'do nothing' or not when booting up. it's annoying if i select hibernate after downloading hugh file before bed yesterday, and today i boot up and use flashfxp a little and it goes to sleep unexpectly as i totaly forget the hibernate option i set before.

all other shutdown function actually shutdown (and reset) flashfxp. but suspend/hibernate will remain flashfxp there and this could cause confusing.

[bigstar]

Originally Posted by msg7086

BTW, the 'suspend/hibernate after queue completed' function could display an extra prompt to choose if the function would be reset to 'do nothing' or not when booting up.

It only remains active if you set it via the Preferences, as this is the default value that is used on startup (Changing the setting via the preferences doesn't apply to the current session).

To have it apply to the current session only set it via main menu > Session > On Transfer Complete. (This setting is not saved on exit)

[msg7086]

Originally Posted by bigstar

To have it apply to the current session only set it via main menu > Session > On Transfer Complete. (This setting is not saved on exit)

i mean, hibernate / suspend the computer won't close the flashfxp window. thus the session setting will remain to next time i use it. user may forget what they did last time and reuse the current flashfxp window and that cause the problem.

hope you read my poor english

[bigstar]

Originally Posted by msg7086

all other shutdown function actually shutdown (and reset) flashfxp. but suspend/hibernate will remain flashfxp there and this could cause confusing.

Oh I see what you're saying, your right, since FlashFXP doesn't shutdown in those two situations on resuming the OS the user might not remember the last setting, I will make this reset back to "do nothing" after being triggered.

[msg7086]

switch off 'modern toolbar' option causing flashfxp stop responsing, even kill it and restart.

flashfxp.ini
[toolbar]
modern=1 <--- This option
back=
button=Classic
Navbutton=Classic

appears on my pc, windows server 2008r2, remote desktop connecting from my laptop, no aero, newly upgraded to 1629 build.