No Directory Refreshing after Transfer files in the local Browser

[Buliwyf1]

Hi i am a licensed User for a long time
no problems.But here is one since the
last update-.


After i have transfer Data Folders the Local Browser remains empty
there is no way to see the content in the Folders,i have to restart
flshfxp to get things running.This is since the last update.Never have
this before.New Install not help to solve the bug.

FlashFXP version: 5.2.0 (build 3906)
Operating System: Windows 7 Service Pack 1

Best Regards and happy xmas to all

[bigstar]

What version/build did you upgrade from?

Is the local path a fixed drive, removable drive, network share, etc?

Does pressing the F5 key or navigating to the parent folder and then back update update the file listing?

Do you see the "Parent Directory" item in the file listing?

[Buliwyf1]

1. Download here and install fresh from 5.2.0 build 3906
2. The Local Download Path is a on MB connected SATA2 WD HD Drive
3. NO

i put a screenshot here to see whats going on after Transfer Files somehow

[bigstar]

Do you recall which version/build you upgraded from or how long ago? I am not seeing any changes made in the last 2 months that would explain this mysterious problem.

I am not sure what's causing this problem; it's very unusual and I have not been able to reproduce it.

What folder is the local browser in before the transfer completes? It's odd that you're ending up in the "computer" drive list area after the queue is completed because this location is a special folder and typically you wouldn't end up here.

If you click the local browser path dropdown does it show any entries, can you select one?
If you type in c:\ in the dropdown text box and then press enter does it switch to the c:\ drive?

[Buliwyf1]

so at the moment flash fxp works without this
unusual problem,i dont know why but i hope
it stays this way,i will keep an eye of it and
when it happens again,i will provide more
details on this weird problem,for the moment
this problem is gone.

Best wishes for all of you for 2k16

Greets from Germany

Buliwyf

[DayCuts]

I can confirm this issues also occurs for me (was just coming to the forums to check/report it)

Build 3906, previous build before updating was 3901 (i think), Windows Vista Home Premium 32bit.

This only occurs under certain circumstances.

To reproduce...
-Ensure 'on transfer complete' option is set to 'idle'
-Queue some files/folders for local download and begin transfer
-Minimize session to system tray
-Wait for queue to finish transferring (no errors in my examples)
-Maximize session from system tray

Answering your questions...
-Local path is a fixed drive
-Pressing F5 or navigating does not update the local file listing.
-The parent directory ICON is visible, but not the text... you can scroll and move around the listing as if the contents were there (even typing the name of a known directory and hitting enter to navigate into it) HOWEVER as soon as you leave the current directory the local listing window become completely empty (no parent directory icon, no knowledge of new cwd contents, etc). Hitting CTRL+L or CTRL+N will cause flashfxp to become aware of the new cwd contents but it is still not drawn to the interface (back to the initial error state)
-Both local browser navigation tree and path dropdown show correct information at all times. Selecting or typing in either to navigate functions but does not correct the issue (same affect as keyboard navigation as outlines in previous point)

In order to fix it properly in an open session I found that I have to perform a remote connection or disconnection (either will do).

Notes...
-If the "On Transfer Complete" operation is NOT set to Idle then this bug does not occur (rather I assume it does occur but the automatic disconnection forces the correction)
-As a side note, usually flashfxp will return to the initial working directory on both remote and local sides after queue has finished, but while re-testing to post this comment I noticed that when On Transfer Complete is set to Disconnect Sites this operation is not performed on either side. While it may not be necessary on all remote connections because it is just going to disconnect (then again if you are caching and the remote listing are not cleared on disconnect then it should actually return still), it should always return to the initial working directory in the local browser.

[bigstar]

DayCuts

Thank you so much for the detailed steps to reproduce the problem.

While I was not able to reproduce the problem, your report has allowed me to narrow down my search and limit my code review to this specific area; By limiting the scope of the changes I was able to determine a possible explanation to the problem.

When FlashFXP is restored from the system tray I suspect that a critical window event is not being fired, the event WM_WINDOWPOSCHANGED

How is this even possible? I am not sure, but I am fairly sure this is the case.

Now to fully understand the situation we need to back up and start from the top, when the main application window is minimized to the taskbar or to the system tray we stop updating some of the window UI elements, when the window is restored we resume updating the UI elements.

This goes beyond just your typical windows painting/drawing, but also extends to content updates via Windows API's, such as setting the listview item count, item selection, etc.

One of the specialty hooks for the local browser taps into the parent window WM_WINDOWPOSCHANGED event to pause updates and it appears that this code isn't being called after the main window is restored to resume updates.

This problem came about due to what should of been a simple code change, I noticed that the original code was polling several API's such as IsWindowVisible() and IsIconic() every couple seconds, and I thought this was silly, why poll the current window state when a flag can be set to reflect the current state, when the window state changes the flag is updated to reflect the current state. Except I did not count on a situation where some window events might not be triggered and this left the flag in the wrong state.


Reflecting back I do recall a situation several years ago with WM_WINDOWPOSCHANGED, where instead WM_SIZE and WM_MOVE are sent instead and WM_WINDOWPOSCHANGED is never triggered. Doh!

Due to some unrelated and very unexpected issues with the authenticode verification component used within FlashFXP (it doesn't support validating authenticode signed files with dual timestamps). It will be a couple days to test the updated component to make sure it works as expected. (though this has created another unexpected and critical problem, we validate the authenticode signature after downloading updates, if we dual sign them then the verification check fails.. all current versions will fail to verify updates that are dual signed. only after the fixed update is installed can dual signed updates be installed)

[tk_1]

I have the same probleem, to the extend that I can not trust FlashFXP at this time.
It took me a few hours before I discovered that with a direct link to my server the files in fact were tranferred.

Do you have any idea when this will be solved? (Can't really work without FlashFXP ;-))

Tom

[Buliwyf1]

Hi @all

With the new Update (FlashFXP version: 5.2.0 (build 3910)
the problem seeem to be solved to me.I will keep an Eye
of it.

Thx for the New Update.

Have nice Weekend