Random blank screen at connection about flamerobin HOT 12 CLOSED

Looks like don't occurs at debug, just in the "Release Dynamic" build

from flamerobin.

Can we get a clear picture of what's happening?

• Does the connection still open?
• What method of opening is being used (e.g. double-click on registered DB)
• What version of wxWidgets (check About dialog)

Looks to me like some kind of race condition in wx setting up the dialog. So I guessed at a possible solution in pull req #117

from flamerobin.

I'll try 3.1.4
I'll give a try to stable 3.0.5 too, (don't know if will compile)

from flamerobin.

Apparently with the new cmake build it's working

from flamerobin.

HI @arvanus

This issue has happened to me several times but I was unable to identify a sequence of steps that was 100% reproducible.
This is an easier issue to be seen on high latency networks.
In other words, this is a valid issue and I hope you can find the root cause.

Best Regards,
Luciano

from flamerobin.

I think it's something related to the thread while connecting, it's an easy stuff to mess with, and hard do find
😢
Unfortunately I have a little experience with threads in c++, and as it's not really and blocking bug, I won't try to fix it right now

from flamerobin.

Hi @arvanus

Did you have the opportunity to compare the current source code with the source code for version 5ece15b?
I am almost 100% sure that in version 5ece15b this issue would not happen.
Comparing the current code with the 5ece15b code can help you identify the issue.

from flamerobin.

0.9.3.1...master
Looking across versions, I couldn't find much changes
I would list major changes: WINVER change from WINVER=0x400 to WINVER=0x500 and wxWidget change...
The change list aren't that long but off-course I could miss something

from flamerobin.

If we don't have so many changes compared to the 5ece15b version, we are probably seeing this issue because the executable is not optimized.

Lets wait for the @mariuz reply in the issue #38 and retest this issue with the optimized version of flamerobin.

from flamerobin.

I doubt that the lack of optimization is the cause. In fact to much optimization at compiler level can lead to some strange bugs like this small example:
https://developercommunity.visualstudio.com/content/problem/161765/c-compiler-bug-optimization-with-demo-code.html
But of course everything must be tested

from flamerobin.

Can we get a clear picture of what's happening?

* Does the connection still open?

Yes

* What method of opening is being used (e.g. double-click on registered DB)

double-click

* What version of wxWidgets (check About dialog)

3.1.3

Looks to me like some kind of race condition in wx setting up the dialog. So I guessed at a possible solution in pull req #117

This bug just occurs randomly in release mode,when I'm running in debug mode never occurred
I'd guess it's related to some c++ optimization in release....

from flamerobin.

* What version of wxWidgets (check About dialog)

3.1.3

Have you tried 3.1.4? Seeing as wx3.1 is the development branch, it's likely they've created some bugs along the way. Seen problems like this before in other desktop GUI libs (Qt, IUP), and it's usually a case of forcing the dialog to layout.

TBH I've just been using the wx debug DLLs for code work, I should really build the static libs.

from flamerobin.