Re: Last call for issues affecting release of gnuplot 5.0

[sfeam <sf...@us...>]

On Wednesday, 31 December 2014 09:53:22 AM Bastian Märkisch wrote:
> > The code changes to files in .../src/win have not been tested at all
> > by me.  Please confirm that they at least compile under MSWin!
> > It would of course be even better if they do in fact fix the
> > "pause mouse" issues.
> >
> 
> I have checked in another fragment for the wxt terminal which is 
> referenced by the code in src/win/wpause.c. Now it compiles fine. Using 
> wgnuplot, bug #1432 is resolved for wxt and windows (but not for qt and 
> caca - as expected), bug #1502 is resolved for qt, windows and wxt. 

You are referring to this bit, right?

+TBOOLEAN wxt_active_window_opened(void)
+{
+       return ((wxt_current_window != NULL) &&
+               (wxt_current_window->id == wxt_window_number) &&
+                wxt_current_window->frame->IsShown());
+}

I hope that works correctly.  It looks very similar to the malfunctioning
bit in wxt3.0 that was causing problems on linux.  The issue in that
case was that frame->IsShownOnScreen() does not act as documented;
it can return true even if the window is not currently shown.  So far
as I can tell, a correct description of the routine is something like
"returns true if a request to display the frame has previously been
registered".  In other words, it only means that the window was
requested - not that it actually was drawn and is currently visible.
I think frame->IsShown() offers an even weaker guarantee than 
frame->IsShownOnScreen().

If the same is true for the wx implementation on Windows,
you might still get stuck waiting for a mouse event in a window that
was never actually drawn to the screen for some reason.

	Ethan