gnuplot-beta — Developers and beta testers of new gnuplot code

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

> Hans-Bernhard Bröker wrote:
> > Benjamin Lindner wrote:
> > 
> > [about wgnuplot 4.4 candidate:]
> >> There is still one issue open I believe:
> >> - Copying to clipboard as metafile is broken.
> > 
> > Broken how, exactly?
> > 
> 
> in the way that the command
> 
>   plot sin(x) with linespoints, cos(x) with linespoints
> 
> produces the attached term window, but when doing Options->Copy to
> Clipboard
> and then pasting as Metafile in openoffice the result looks like the 
> second attachment.

and if pasted into microsoft word, then the result looks like the
attached png.
This certainly looks better than when pasted into OO but it's
also broken as the text disappears, and the marker points also.

benjamin

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Re: towards 4.4 (pause for keyboard for gnuplot.exe on windows)

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik  wrote:

> 
> I think the loop waiting for Enter is the most appropriate solution.

OK. 
I am now quite occupied due to the end of winter term of the university.
I will post the patch in the weekend.

Thanks!

Tatsuro 

--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

Re: towards 4.4 (pause for keyboard for gnuplot.exe on windows)

[Petr M. <mi...@ph...>]

> In gnuplot.exe on windows, we can break pause for key board like 'pause -1' by any key.
> In the manual or the help of pause, it can be broken by only the return key.
> 
> Is it desirable to correct code of pause command for keyboard only be broken by the return key?
> 
> In current state, pause for keyboard on gnuplo.exe by calling term->waitforinput().
> In term->waitforinput(), ConsoleGetch() is used.
> 
> Why I use term->waitforinput() but not fgets(buf, strlen(buf), stdin) is the way to get command
> strings from the prompt gnuplot.exe for windows.  It gets commant strings though ConsoleGetch() so
> that using fgets(buf, strlen(buf), stdin) gave failure to get command string after pause for key
> board.
> 
> If it is desirable  that pause command for keyboard only be broken by return key, I will fix it using
> a loop when return code gotten from term->waitforinput().

I think the loop waiting for Enter is the most appropriate solution.

---
PM

Re: towards 4.4 (pause for keyboard for gnuplot.exe on windows)

[Tatsuro M. <tma...@ya...>]

Hello

In gnuplot.exe on windows, we can break pause for key board like 'pause -1' by any key.
In the manual or the help of pause, it can be broken by only the return key.

Is it desirable to correct code of pause command for keyboard only be broken by the return key?

In current state, pause for keyboard on gnuplo.exe by calling term->waitforinput().
In term->waitforinput(), ConsoleGetch() is used.

Why I use term->waitforinput() but not fgets(buf, strlen(buf), stdin) is the way to get command
strings from the prompt gnuplot.exe for windows.  It gets commant strings though ConsoleGetch() so
that using fgets(buf, strlen(buf), stdin) gave failure to get command string after pause for key
board.

If it is desirable  that pause command for keyboard only be broken by return key, I will fix it using
a loop when return code gotten from term->waitforinput().

Any comments?

Regards

Tatsuro


--- Tatsuro MATSUOKA  wrote:

> Hello
> 
>  --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> > 
> > BTW, I found the my fix for 'pause mouse' shows different results whether gnuplot is built
> > with
> > wxt or
> > without wxt.  I will fix it. 
> 
> The  my completely comes from my miss operation. Sorry for the noise.
>  
> Regards
>  
> Tatsuro
> 
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 


--------------------------------------
VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi]
http://pr.mail.yahoo.co.jp/olympic/

save and multiplot

[adhemar <ek...@gm...>]

Hello everybody,

I am unable to save all the "plot" commands that I've given inside the
multiplot mode, but it appears to only save the last plot command that I've
issued.

For example:

set multiplot layout 2,2
plot x
plot x**2
plot x**3
plot x**4
save "example.gp"
unset multiplot

produces a file containing a lot of settings and then only the last command,
i.e. plot x**4.
Is this working as intended? Is there a way to save all the plot commands I
have given in multiplot mode?

Thank you.

-- 
View this message in context: http://old.nabble.com/save-and-multiplot-tp27413719p27413719.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

Hans-Bernhard Bröker wrote:
> Benjamin Lindner wrote:
> 
> [about wgnuplot 4.4 candidate:]
>> There is still one issue open I believe:
>> - Copying to clipboard as metafile is broken.
> 
> Broken how, exactly?
> 

in the way that the command

  plot sin(x) with linespoints, cos(x) with linespoints

produces the attached term window, but when doing Options->Copy to Clipboard
and then pasting as Metafile in openoffice the result looks like the 
second attachment.

benjamin

hypertarget labels - Re: Two Questions

[Petr M. <mi...@ph...>]

So here is the solution:

...
\usepackage{hyperref}
...
\label{bla} \hypertarget{bla}{}
...

pdflatex x.tex
pdflatex x.tex
acroread /a nameddest=bla x.pdf
   ... jumps to that label

Unfortunately, if the file has been already opened, then it does not scroll 
to that position (contrary to labels in html).


> What does Adobe understand with nameddest??
> Like you, I thoight it woukld be a hyperref book mark.
> But I think, Adobe would not refer to hyperref, that's a Latex term.
> Just some thought, but thank you for your mail!!
> 
> > > > Looking at the acroread manpage
> > > > (http://transit.iut2.upmf-grenoble.fr/cgi-bin/man/man2html?acroread+1),
> >
> > > > one can find the "/a" switch that has a "nameddest=..." option. Regular
> >
> > > > bookmarks do not seem to work. However, maybe you find another way to
> > > > create named destinations in your PDF.
> > > I have been looking for that all over!!
> >
> > Did it work for you?
> >
> > All these command line options are summarized here:
> > http://www.adobe.com/devnet/acrobat/pdfs/pdf_open_parameters.pdf
> >
> > Unfortunately,
> > ...
> > \usepackage{hyperref}
> > ...
> > \label{hello}
> >
> > and then
> >        pdflatex x.tex
> >        acroread /a nameddest=hello x.pdf
> >
> > does not go to the tag, contrary to
> >        acroread /a page=4 x.pdf
> >        acroread /a search=something x.pdf
> > which work OK.
> >
> > Has somebody succeeded in hyperref+label+nameddest?

---
PM

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

 --- Tatsuro MATSUOKA <tma...@ya...> wrote:
> 
> BTW, I found the my fix for 'pause mouse' shows different results whether gnuplot is built
> with
> wxt or
> without wxt.  I will fix it. 

The  my completely comes from my miss operation. Sorry for the noise.
 
Regards
 
Tatsuro


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: pause mouse does not work on windows term on gnuplot.exe (on wgnuplot, pause mouse works correct)

[Tatsuro M. <tma...@ya...>]

Hello

Sorry for delayed reply
At that time, I have completely misled what you said.



--- Benjamin Lindner  wrote:


> Not really. It also waits for mouse input.
> That's the reason (I suspect) that the function is written the
> way it is written. It processes mouse events in the else clause
> 
>         else if (waitResult == WAIT_OBJECT_0+1)
>          {
>              MSG msg;
> 
>              while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
>              {
>                  TranslateMessage(&msg);
>                  DispatchMessage(&msg);
>              }
>          }
> 
> because otherwise you would not be able to zoom.
> However it does not return on mouse input.
> I don't know if it should do so?

You are right. ConsoleGetch(); used in win.trm is described in the winmain.c and include the code you
have described the above.  So it is used for only pause for keyboard.

Regards

Tatsuro 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Petr M. <mi...@ph...>]

> >  - If an x11 plot window is killed, then a subsequent 'pause mouse'
> >    command should be rejected.  The only way I have managed to set this up
> >    so far is to have event_reset() set term_initialised = FALSE,
> >    and have pause_command() test for it.  This seems to work for x11, but
> >    I have no idea what havoc it might trigger on os2 or whatever else.
> 
> os2?!  I love gnuplot, but when I try to delve into the code base
> I'm struck by the opacity induced by trying to support Dinosaur
> OSes.  I think some have been cleaned out lately (?) but if os2
> has not, then time to go?

Nowadays you can buy modern OS/2 under the name eComStation, see
   http://www.ecomstation.com
where you can even try a DemoCD.

The OS/2 community is quite active, see web pages such as
   http://hobbes.nmsu.edu/h-browse.php?dir=/pub/new&sort=date

There is absolutely no reason to remove the OS/2 support.

And neither DOS support - the latest gnuplot compiled by DJGPP runs well in 
DOS. You find such machines in labs running various experimental tools.

Greetings,
  Petr

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan Merritt  wrote:

> On linux it is always safe to hit "ctrl-c" in order to return to
> the command prompt. As I understand it, this solution does not work
> on windows (see other thread).

I understand the situation.  

BTW, I found the my fix for 'pause mouse' shows different results whether gnuplot is built with wxt or
without wxt.  I will fix it. After that I will try to CTRL+C problem using win32 api of
SetConsoleCtrlHandler.    

in the below

http://msdn.microsoft.com/en-us/library/ms685049(VS.85).aspx

I do not know fix will be successful and fix itself apparently goes well but it break the pipe
communication that is mentioned by Benjamin.

http://old.nabble.com/Re:-towards-4.4-p27395529.html

For wgnuplot, perhaps the ConsoleCtrlHandler can not be used I cannot find the way to do at the
moment.

My knowledge is not enough for win32 programing so that it will take a time and Febrar

At the moment, I vote to Benajmin's opinion and please go ahead to the 4.4-rc2.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Ethan M. <merritt@u.washington.edu>]

On Sunday 31 January 2010, Tatsuro MATSUOKA wrote:
> Hello
> 
> --- Ethan Merritt <merritt@u.washington.edu> wrote:
> 
> > I have this listed already as an un-fixed bug.
> > "pause mouse" should return immediately, perhaps with a warning,
> > if the there is  no mousable window present.
> > Here are my notes:
> > 
> >  - If an x11 plot window is killed, then a subsequent 'pause mouse'
> >    command should be rejected.  The only way I have managed to set this up
> >    so far is to have event_reset() set term_initialised = FALSE,
> >    and have pause_command() test for it.  This seems to work for x11, but
> >    I have no idea what havoc it might trigger on os2 or whatever else.
> 
> Sorry I have not noticed the above.
> Surely gnuplot with x11 on cygwin (in this case, cygwin can be included as a unixy system),
> 
> pause mouse" return immediately, perhaps with a warning, if the there is  no mousable window present.
> 
> gnuplot> pause mouse
>          Mousing not active

That is because you have not yet opened a plot window at all, right?
Therefore gnuplot_x11 has not yet been started.
The problem arises if there was previously a plot window in use,
but it was forcibly closed by the user.

> In x11.trm,
>     /* If ipc_back_fd is not open, we will never see any mouse events! */
>     else if (paused_for_mouse) {
> 	paused_for_mouse = 0;
> 	int_error(NO_CARET,"Mousing not active");

That test only confirms that there is an open pipe to gnuplot_x11, 
not that there is currently a plot window on the screen.

> Perhaps on windows terminal can be done this by 'graphwin.hWndGraph'.
> For wxt terminal, I do not have enough knowledge to do that.
> 
> BTW, does not wxt terminal on the linux have the same problem?

On linux it is always safe to hit "ctrl-c" in order to return to
the command prompt. As I understand it, this solution does not work
on windows (see other thread).

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan Merritt <merritt@u.washington.edu> wrote:

> I have this listed already as an un-fixed bug.
> "pause mouse" should return immediately, perhaps with a warning,
> if the there is  no mousable window present.
> Here are my notes:
> 
>  - If an x11 plot window is killed, then a subsequent 'pause mouse'
>    command should be rejected.  The only way I have managed to set this up
>    so far is to have event_reset() set term_initialised = FALSE,
>    and have pause_command() test for it.  This seems to work for x11, but
>    I have no idea what havoc it might trigger on os2 or whatever else.

Sorry I have not noticed the above.
Surely gnuplot with x11 on cygwin (in this case, cygwin can be included as a unixy system),

pause mouse" return immediately, perhaps with a warning, if the there is  no mousable window present.

gnuplot> pause mouse
         Mousing not active


In x11.trm,
    /* If ipc_back_fd is not open, we will never see any mouse events! */
    else if (paused_for_mouse) {
	paused_for_mouse = 0;
	int_error(NO_CARET,"Mousing not active");

Perhaps on windows terminal can be done this by 'graphwin.hWndGraph'.
For wxt terminal, I do not have enough knowledge to do that.

BTW, does not wxt terminal on the linux have the same problem?

Regards

Tatsuro 

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Allin C. <cot...@wf...>]

On Sun, 31 Jan 2010, Ethan Merritt wrote:

>  - If an x11 plot window is killed, then a subsequent 'pause mouse'
>    command should be rejected.  The only way I have managed to set this up
>    so far is to have event_reset() set term_initialised = FALSE,
>    and have pause_command() test for it.  This seems to work for x11, but
>    I have no idea what havoc it might trigger on os2 or whatever else.

os2?!  I love gnuplot, but when I try to delve into the code base
I'm struck by the opacity induced by trying to support Dinosaur
OSes.  I think some have been cleaned out lately (?) but if os2
has not, then time to go?

Allin Cottrell

Re: paused

[Ethan M. <merritt@u.washington.edu>]

On Sunday 31 January 2010, Petr Mikulik wrote:
> There is a bug in
> 	pause -1
> which appears on Windows only:
> 
> pause -1
>   ... prints "paused"
> pause -1 "hello"
>   ... prints "hello"
> pause -1
>   ... prints "hello" instead of "paused"
> 
> The fix in command.c is easy:
>     if (END_OF_COMMAND) {
> 	free(buf);
> 	buf = gp_strdup("Pausing...");
> 
> My question is: wouldn't "Pausing..." instead of "paused" be a better 
> message?

Why?  It has already paused by the time it prints the message.

Re: towards 4.4

[Ethan M. <merritt@u.washington.edu>]

On Sunday 31 January 2010, Petr Mikulik wrote:
> 
> I see this on Linux:
> set term wxt
> plot x
> <close the window>
> pause mouse any
> <need to press Ctrl-C>
> 
> The same for "set term x11".
> On "set term windows": <need to press Enter>
> 
> I think it would be better to require <Enter> on all platforms if wxt or x11 
> window is not available.

I have this listed already as an un-fixed bug.
"pause mouse" should return immediately, perhaps with a warning,
if the there is  no mousable window present.
Here are my notes:

 - If an x11 plot window is killed, then a subsequent 'pause mouse'
   command should be rejected.  The only way I have managed to set this up
   so far is to have event_reset() set term_initialised = FALSE,
   and have pause_command() test for it.  This seems to work for x11, but
   I have no idea what havoc it might trigger on os2 or whatever else.

paused

[Petr M. <mi...@ph...>]

There is a bug in
	pause -1
which appears on Windows only:

pause -1
  ... prints "paused"
pause -1 "hello"
  ... prints "hello"
pause -1
  ... prints "hello" instead of "paused"

The fix in command.c is easy:
    if (END_OF_COMMAND) {
	free(buf);
	buf = gp_strdup("Pausing...");

My question is: wouldn't "Pausing..." instead of "paused" be a better 
message?

---
PM

Re: towards 4.4

[Petr M. <mi...@ph...>]

> Although there remained some problems, I have attached the patches

I've committed them.

> The most serious problem remained is gnuplot hangs if the pause mouse 
> command executed when wxt graph windows does not exist or is terminated by 
> a user.

It seems to need a variable or function ... e.g.
is_wxt_windows_active()?

I see this on Linux:
set term wxt
plot x
<close the window>
pause mouse any
<need to press Ctrl-C>

The same for "set term x11".
On "set term windows": <need to press Enter>

I think it would be better to require <Enter> on all platforms if wxt or x11 
window is not available.

---
PM

Re: towards 4.4

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Thursday 28 January 2010 15:33:48 Tatsuro MATSUOKA wrote:
>> Hello
>>
>> I have remembered that Benjamin have posted concerning issue of ctrl+c on gnuplot.exe for windows.
>>
>> http://old.nabble.com/MSWin-issues-holding-up-4.4.rc1-td25793940.html#a26015183
>>
>> ****************
>> --- gnuplot-4.3.0-2009-07-08-orig/src/plot.c	2009-09-20 20:16:47 +0200
>> +++ gnuplot-4.3.0-2009-07-08/src/plot.c	2009-10-18 13:06:08 +0200
>> @@ -684,7 +684,11 @@
>>      setmatherr(purec_matherr);
>>  #endif
>>  
>> +#if defined(WGP_CONSOLE)
>> +    (void) signal(SIGINT, SIG_IGN);
>> +#else
>>      (void) signal(SIGINT, (sigfunc) inter);
>> +#endif
>>  
>>  #ifdef SIGPIPE
>>      /* ignore pipe errors, this might happen with set output "|head" */
>> ******************
>>
>> The above seems not to be applied yet.
> 
> That would cause the program to ignore ctrl-c.

That's what the windows GUI version does...

> It would be better to fix the signal-handling routine so that it
> responds to ctrl-c correctly.

True, but at the current stage pressing ctrl+c segfaults gnuplot
and personally I'd prefer it to simply ignore it than to segfault.
If you execute gnuplot as piped child process as e.g. octave does,
then there is no interactive stdin so ignoring ctrl+c is a quick
and simple though maybe not elegant solution of the problem.

Besides the signal-handling responds correctly, but the longjmp in 
bail_to_command_line() fails.

> Does someone know the history of this problem?
> Did ctrl-c work on Windows in older versions of gnuplot?

With older versions you mean the gui version? These ignored ctrl+c to my 
knowledge.

benjamin

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

Although there remained some problems, I have attached the patches 
and uploaded the exe files for pause mouse for gnuplot for windows with wxt terminal.

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/diff.exes.html
(Please forgive me this page will be deleted in the future.
uploaded Jan. 31, 2010 )

Note that the exe files can be used override them to 
gp45-winbin.zip + gp45-winbin-wxt-diff.zip.
in
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin


The patch is made for the cvs source. The latest chagelog is

2010-01-28  Petr Mikulik  <mi...@ph...>

	* src/command.c (pause_command): Fix "pause mouse" for gnuplot.exe on
	Windows.

#########################

The most serious problem remained is gnuplot hangs 
if the pause mouse command executed 
when wxt graph windows does not exist or is terminated by a user.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

The previous post has a mistake. Please ignore it.

--- Petr Mikulik wrote:
> But in wxt_gui.cpp there is a special code for WGP_CONSOLE and not for 
> WIN_IPC in wxt_waitforinput().

Ooops! I have not noticed.

#ifdef WGP_CONSOLE
	if (paused_for_mouse) {
		MSG msg;
		BOOL ret;
 :
 :

I have changed #ifdef WGP_CONSOLE to #ifdef _Windows in wxt_gui.cpp

Your patch almost works for wgnuplot.  However, if the graph window of wxt (wxtFrame?) terminal
(wxtFrame) is not active, for example the graph window is closed by user, 'pause mouse'  freezes the
wgnuplot. 

(In the previous post I wrote 'is active' but 'is not active' is correct  )

This is also happen in gnuplot.exe

The explanation of wxtFrame is written in wxt_gui.cpp as, 
/* ---------------------------------------------------------------------------
 * Frame : the main windows (one for each plot)
 * ----------------------------------------------------------------------------*/

I would like to know flag for wxtFrame similar to 'graphwin.hWndGraph'  
in windows terminal.

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik wrote:
> But in wxt_gui.cpp there is a special code for WGP_CONSOLE and not for 
> WIN_IPC in wxt_waitforinput().

Ooops! I have not noticed.

#ifdef WGP_CONSOLE
	if (paused_for_mouse) {
		MSG msg;
		BOOL ret;
 :
 :

I have changed #ifdef WGP_CONSOLE to #ifdef _Windows in wxt_gui.cpp

Your patch almost works for wgnuplot.  However, if the graph window of wxt (wxtFrame?) terminal
(wxtFrame) is active, for example graph window is closed by user, 'pause mouse'  freezes the wgnuplot.
This is also happen in gnuplot.exe

The explanation of wxtFrame is written in wxt_gui.cpp as, 
/* ---------------------------------------------------------------------------
 * Frame : the main windows (one for each plot)
 * ----------------------------------------------------------------------------*/

I would like to know flag for wxtFrame similar to 'graphwin.hWndGraph'  
in windows terminal.

Regards

Tatsuro

Regards






--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: png terminal : font bug on windows binaries 4.5

[Tatsuro M. <tma...@ya...>]

Hello

Sorry for my late reply.

The error seems to come from detecting binary/etc/fonts/fonts.conf

In the folder of binary, can you find  etc/fonts/fonts.conf?
If the file located correctly, it should work correct.

If you do not find it, it is my packaging error.  Quick fix is to copy binary/etc/fonts/fonts.conf of
4.4rc1, from 20091205 to corresponding directry.

If etc/fonts/fonts.conf exists, I cannot figure out the cause.
In that case, please try to set environmental variable 'FONTCONFIG_PATH'
for exaple
set FONTCONFIG_PATH=c:\Program Files\gp45-winbin\gnuplot\binary\etc\fonts
or in the control panel.
--- Sebastien Kramm  wrote:

> Hello,
> with the 4.5 windows binaries (2010-01-12) available from here:
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> I (seem to) have found a bug:
> gnuplot is unable to load the windows tt fonts.
> 
> description:
> -unzip, start wgnuplot, and type the following:
> 
> gnuplot> set term png font "verdana,14"
> Terminal type set to 'png'
> fontconfig: Couldn't retrieve font file name. when opening font verdana, trying
> default
> fontconfig: Couldn't retrieve font file name. when opening font "arial", using i
> nternal non-scalable font
> Options are 'nocrop medium size 640,480 '
> 
> Although I have the GDFONTPATH env. variable defined, and pointing to
> c:\windows\fonts
> 
> This was ok with previous release (4.4rc1, from 20091205)
> 
> And thanks everybody for this great tool !
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: towards 4.4

[Hans-Bernhard B. <HBB...@t-...>]

Ethan Merritt wrote:

> Does someone know the history of this problem?
> Did ctrl-c work on Windows in older versions of gnuplot?

To the best of my recollection, no.

Re: towards 4.4

[Petr M. <mi...@ph...>]

> Anyway the problem wgnuplot+wxt+pause mouse does not work now.
> I have remembered that my personal trial to treat wgnuplot+wxt+pause mouse
> issue was failed in this point.

Please try the hint in my previous email with
  if (0) {

> I have one point to ask about the wxt terminal. Is there any way to detect whether the wxt graph
> window is active or not.

This:
  if (!strcmp(term->name, "wxt")) {


---
PM