Not maximising from tray back to full screen

Just returned from a lengthy holiday and flashfxp auto updated to the latest version. However, on several occasions since when I maximise the application from the system tray (I have the minimise to system tray option ticked) the application does not restore to full screen and only occupies a window on the left hand side of my 2560x1440 display.

Sadly, this doesn't happen all of the time, but seems to happen more frequently when a transfer queue has completed and the flashfxp icon is flashing.

I've tried several older versions, but the last one that I can find that does not produce this error is 4.2.3 build 1770

That is quite strange, We haven't made any changes to this in quite some time and I believe the last time we touched this code was back when we fixed the flicker problems with the restore from tray. Last changes were done in march. if 1770 doesn't do it. i just don't know, there were no code changes between 1770 and the current build related to the tray icon or minimizing/restoring.

I spent about 30 minutes trying to reproduce the problem, I'll leave FlashFXP running with the tray icon flashing all night and see if it happens when I restore it in the morning.

I been trying to duplicate this, but have been unable to.

Would be nice if I could see a couple of screenshots of this bug, specially when flashfxp only occupies a window on the left side of screen as described.

cheers.

Thanks for the update, next time it happens I'll get a screen grab and post it here.

It happened again yesterday using build 1836 - but prior to that I had rolled back to 1770 and had no issue at all

Here is a screenshot



Transferred a queue, maximised from the tray when the icon is flashing and flashfxp goes to a window on the left hand side of the screen when it should go back to full screen

resolution 2560x1440 - fonts etc. set at 125%
latest nvidia whql drivers (have tried beta ones too in case it is a display driver issue)

Problem is intermitant, so it doesn't happen every time.

Last version that it doesn't happen on at all I can find is 1770 (although the archive of past releases given in the forum hasn't been updated in a while and several releases that are in the release history are missing

Can you test.

1) With fonts at 100% will this happen?

and

2) Windows snap (looking at your screenshot looks like its snapped on left... (I have it on right by choice/as per my settings.

WINKEY + LEFT ARROW – Snap current window to the left side of screen; unsnap window that is snapped to right side of screen

WINKEY + RIGHT ARROW – Snap current window to the right side of screen; unsnap window that is snapped to left side of screen

WINKEY + TOP ARROW – Maximize current window.

WINKEY + BOTTOM ARROW – Minimize current window; restore maximized window.

Change the position/size of window before sending it to tray via shortcuts above.

Will the window restore to position you left it and size? Or what happens?

Dont hesitate to post screenshots.

Cheers.

Thanks for the update, I'll follow the advice and provide extra screen shots later on.

Couple of things though, this only ever happens when the flashfxp icon is flashing in the tray to let me know that a queue has been completed. If the icon isn't flashing then it will restore to full screen every time. Also, with this bug being specific to certain builds of flashfxp (post 1770) I am having a hard time seeing that this is caused by anything external to the program.

I found a way to reproduce this problem and I now know why its occurring, however its going to take me some time to come up with a work around solution to this problem.

Originally Posted by bigstar

I found a way to reproduce this problem and I now know why its occurring, however its going to take me some time to come up with a work around solution to this problem.

Excellent news, thank you for your attention to detail here. I will roll-back to 1770 and await your solution when it presents itself

I managed to duplicate this with fonts at 125%, I maximize window to full, initiate a transfer and send FFXP to tray, once completed instead of restoring windows to full, it snaps it to either left or right.

It consistently showed this in action every try.

Gone back to 100% font size and all is well....

On a side note FFXP looks much out of place with 125% fonts. Always was a problem that.

Lets see what spudgun says.

Cheers Bigstar looking forward to the solution.

Please try this update and let me know if it resolves the problem

FlashFXP42_1837_Setup.exe

As for my part, build 1837 it seems now if set @ 125% font size dont affect how FFXP restores window sizes.
on a side note The UI and specifically the tray pop-up dialog is slightly crowded because fonts at 125% just dont have room to fit in same amount of space. Some sort of adjustment there and other areas (filters buttons) may be necessary if possible at all to match File transfer rules button alignment.

I'm running at 2560x1440 on a 27" monitor, so unless you have eyes like a hawk 100% font size is very difficult to use for long periods of time and flashfxp seems to be perfectly usable at the 125% zoom level.

The revised build does fix the issue, but has the side effect of drawing the screen when it maximises and then moving things to their correct place.

As this seems to be caused by the 125% font setting, I am currently testing build 1813 (the latest build from the download page) at a custom font setting of 120% and so far the drawing issue hasn't presented itself.

I'll update more over the weekend

Latest version also has the issue - so the change to 120% had no effect.

I'll go back to 1770 as that works perfectly, would it be possible to have whatever code makes it work in 1770 in later releases as that is by far the best one for this issue?

This is a bit of a catch22.

I need to finish getting ready for my daughters birthday party so I don't have enough time to explain the whole situation right now.

Here's a revised build that makes a couple more changes, I am not entirely sure if it will eliminate the redrawing you're noticing but it might. If not please include some screenshots so I know exactly where to focus.. I'll explain more later when I have some free time.

FlashFXP42_1838_Setup.exe

This whole issue comes back to the changes that I made several months ago to improve the redrawing issue when restoring FlashFXP from the system tray back to a maximized window state.

In order to preserve the window position and size while in the system tray the window is minimized and then hidden, then when restoring the window from the system tray the order is reversed, the window is restored and then shown.

When restoring a window to the maximized state we show the window and restore it to the maximized state.. when restoring a normal window the window is shown and the size is adjusted to the previous size prior to minimizing, typically the size doesn't change while minimized however it can if the resolution changes.

Restoring back to a maximized state requires more work for the OS/video card as most of the content is realigned and positioned.

Its this realignment that prevents the window from restoring correctly under some conditions because the realignment can sometimes create an endless loop where one control resizes and triggers the resize event of the control next to it, which then makes adjustments and triggers a resize event back to the original control.

To prevent this endless loop and a stack overflow we detect when this occurs and stop resizing controls that are looping.

An alternative solution is to disable alignment and then re-enable it after the window state is restored to maximized, however by disabling the alignment we're delaying the redrawing which in turn causes the painting to occur much later and this can lead to flickering or graphic artifacts during restore.

The previous build 1837 disables alignment and then re-enables it, where-as 1838 also does that same but I also adapted some of the code to prevent excessive redrawing, unfortunately this isn't enough to prevent the endless looping on resize.

So why does a flashing tray icon trigger this problem vs a non-flashing tray icon.. Well windows has its own internal overflow protection to prevent endless event loops and I suspect that because FlashFXP isn't totally idle (its animating the tray icon) this additional code is counted as part of the stack, so the animation stack + restore window stack = overflow, where-as if flashfxp was restoring without any animation the overflow doesn't trigger.

Since the main window in FlashFXP is somewhat complex, multiple splitters that scale their position when the window size changes and each splitter adjustment invalidates all adjacent windows, resizing from minimized to maximized might trigger several dozen resize events for a single control. This issue is also amplified by an increased resolution.

Unless there is a way to limit the amount of resize events which I am not sure there is we might have to decide which is more important. Eliminating the flicker on resize or making sure that the window is always restored to the maximized position.

One idea I had was to disable the window animation on restore but this seems to result in unexpected flickering, so its quite possible that if you have windows animation disabled via the OS you're still going to experience some flickering. [UPDATE] disabling windows animation (OS / control panel, performance, adjust visual performance settings) increases the flicker on restore. If you have animation disabled, try FlashFXP with it on.

Please try this update, it works by setting the window style to layered and completely transparent and then shows the window after everything is rendered, this fixes everything for me regardless of the window animation settings.

1. restores from the system tray without flicker. (previous builds always flickered with windows animation turned off).
2. restores from taskbar after minimizing without flicker. (only without animation did previous builds flicker).


FlashFXP42_1839_Setup.exe

Ok now back to the bbq and party..

Thank you so much for your detailed reply. Of the 3 revised builds posted in the thread all of them seem too resolve the problem of not maximising to a full screen with fonts at 125%.

The screen draw issue is caused by akamai netsession client (we've covered this before) as I forgot I'd reinstalled that in order to watch HD videos on nfl.com. With that software installed you get a strange delay in drawing the flashfxp window which disappears as soon as the software is uninstalled.

Therefore, i'd go with whichever build you are happiest with as this strange conflict with netsession client is one that you've tried to tackle before without success (probably as the issue is nothing to do with flashfxp and is akamai's problem).

Hope that the birthday party was a big success

I recall the past problems you experienced when using the akamai netsession client, I decided to re-install it to make sure all my changes were still being applied with akamai netsession client running, and of course some of the changes I made had little to no effect, I made some additional tweaks in build 1840 which is now available as a beta via liveupdate.

The latest build should eliminate all flicker when the akamai netsession client is running when restoring from the system tray. At least it did for me.

Edit: Oops I meant to say build 1840 not 1830.

Thank you once again for all of your help, build 1840 seems to have fixed everything here too

That's awesome, thank you for confirming that the changes resolved all of the issues.