FlashFXP Forums - View Single Post - No Directory Refreshing after Transfer files in the local Browser

bigstar · 01-09-2016, 02:18 PM

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)

01-09-2016, 02:18 PM
bigstar FlashFXP Developer Join Date: Oct 2001 Posts: 8,012	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)