Re: Keyboard input losses also on MS Windows

[Hans-Bernhard B. <br...@ph...>]

On Sun, 4 Jul 2004, Ethan A Merritt wrote:

> On Sunday 04 July 2004 07:46 am, Hans-Bernhard Broeker wrote:
> > Warning:  wgnuplot now tends to lose the first keypress after starting
> > the program.  This did not happen with 4.0.0, and is fixed by back-dating
> > mouse.[ch] and readline.c to that state.
> 
> The last significant change I can see in readline.c is the change 
> 1.33 -> 1.34 (catch EINTR), but that was from 18 Feb 2004 so *before*
> the 4.0.0 tag.

Now that you mention it: right ;-).  A red herring.  On to the next one.

> (1) the pause-for-mouse code - but all of these changes are protected
>     by "if (paused_for_mouse) {...}" so I don't see how they could explain
>     anything that happens immediately on program entry

Agreed.

> (2) the addition of a table of "special keys" (4 Jun 2004).  I can't see
>     anything wrong with this code either, but it's Petr's addition so maybe
>     he can spot something I didn't.

This would be my prime suspect for the moment.

> > Which rather strongly hints at problems with the mousing/keyboard
> > synchronization not only on X11, but also on MS Windows.
> 
> Maybe.  But I don't recall that we ever saw X11 problems on program entry.

Not immediately on program entry, but this problem does feel vaguely like
the early renditions of our select()/buffering problems on X11 / PIPE_IPC,
where e.g. commands typed or piped in while the gnuplot_x11 window was
being started could be dropped, e.g.

	echo -e "plot sin(x)\nplot(cos(x)\n" | gnuplot

might end up with the sine wave plot shown, because the second line of
input was lost in transport.

> None of the recent code additions should be triggered until you actually
> issue a "pause mouse" command.  Is there any conceivable way that
> Windows could manage to start up without having initialized the
> pause_for_mouse TBOOLEAN to FALSE?

I don't think so.

> Does the problem still happen if gnuplot is configured with
> #undef USE_MOUSE ?

To be experimented with.  I'm not even sure the Windows version
still builds in that configuration...

> > But backdating those files to 4.0.0 doesn't cure this problem
> > --- it doesn't seem to occur in 4.0.0 though.
> 
> How about if things are back-dated to just before ANSI-fication?

The OP reported the probleming having appeared considerably earlier than
4.0.1, i.e. before the ANSI-fication.  Anyway, the Windows code was quite
completely ANSI style long before that anyway, since K&R compilers never
existed for MS Windows programs.

But for the record: going back to 4.0.1 didn't help, unless I misremember
the weekend's experiments badly.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.