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

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

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

Hello

Thank you for your information.
I will write the note for the distriution page and my web pase written in Japanese.

Anyway I will try to newer help format by Microsoft HTML help workshop.
Perhaps it will take a lot of time :-).

Regards

Tatsuro

--- Shigeharu TAKENO <sh...@ie...> wrote:

> shige 02/07 2009
> ----------------
> 
> tma...@ya... wrote:
> > I have installed wgnuplot to the PC of one of students in my lab.
> > The OS is windows vista. I found that old type help file used for wgnuplot is
> > not supported on vista
> 
> One solution is to use the following:
> 
> http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb
>
http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb&displaylang=ja
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 


--------------------------------------
Yahoo! JAPAN - Internet safety for children and parents.
http://pr.mail.yahoo.co.jp/security/

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

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

On Saturday 07 February 2009, pl...@pi... wrote:
> Allin Cottrell wrote:
> > On Sat, 7 Feb 2009 pl...@pi... wrote:
> > 
> >> the linux textinfo help has also been criticised recently and I find it
> >> pretty intractable to use.
> >>
> >> Would this be an opportunity to convert the help to one unified,
> >> cross-platform format?
> >>
> >> One obvious possibility is HTML. Although it lacks the nice indexing a
> >> nd cross referencing facilities of winhelp, it would allow
> >> linux/macOS/win* plus web documentation in one hit. This would
> >> presumably be plus for maintainability.
> > 
> > Why would HTML necessarily lack nice indexing and
> > cross-referencing?
> > 
> > Allin Cottrell
> > 
> > 
> No, clearly it could be hand coded or some javascript cobbles from
> somewhere. What I meant is that winhelp has built-in index and search
> facility.

What's wrong with the PDF help?
It has figures, cross-indexing, an index, etc,
generated from TeX.  In principle one can similarly generate HTML docs
from the same TeX document, but I have not been able to find a very 
good latex->html convertor.  There are several old projects, but none
of them seems to be maintained or up to date.

> Maybe the help itself could be more helpful. I've spend quite some time
> this evening trying to plot a sine wave [0:100] but it comes out really
> clunky and distorted. I've been unable to suss out how to set the
> interval to something more than useful than four points per cycle.

set samples <some-large-number>

-- 
Ethan A Merritt

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

[<pl...@pi...>]

Allin Cottrell wrote:
> On Sat, 7 Feb 2009 pl...@pi... wrote:
> 
>> the linux textinfo help has also been criticised recently and I find it
>> pretty intractable to use.
>>
>> Would this be an opportunity to convert the help to one unified,
>> cross-platform format?
>>
>> One obvious possibility is HTML. Although it lacks the nice indexing a
>> nd cross referencing facilities of winhelp, it would allow
>> linux/macOS/win* plus web documentation in one hit. This would
>> presumably be plus for maintainability.
> 
> Why would HTML necessarily lack nice indexing and
> cross-referencing?
> 
> Allin Cottrell
> 
> 
No, clearly it could be hand coded or some javascript cobbles from
somewhere. What I meant is that winhelp has built-in index and search
facility.

There is already an html version of the gnuplot built-in help command
http://amath.colorado.edu/computing/software/man/gnuplot.html#2635

so I suppose the browser text search provides a rudimentary search
ability although it's not as useful as winhelp topics can be in finding
which match relates to what you are looking for.

Maybe the help itself could be more helpful. I've spend quite some time
this evening trying to plot a sine wave [0:100] but it comes out really
clunky and distorted. I've been unable to suss out how to set the
interval to something more than useful than four points per cycle.

That is more a criticism of the content than the format though.

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> > > > > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > > > > > "new window" event from gnuplot_x11, right?  
> > > > > > 
> > > > > > I am trying to point out that not every command "set term x11 <num>" creates
> > > > > > a new window. If an old window is re-used, you won't receive this event and
> > > > > > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > > > > > 
> > > > > > The patch currently has the event generated each time the buffered command
> > > > > > list is re-executed, which I think is not right.  Probably it should go in
> > > > > > pr_window(), immediately after the call to XCreateWindow().
> > > > > 
> > > > > When I tested it, it was filling the variable after the "plot" command has 
> > > > > been completed (not after "set term x11"), i.e. after the graph has been 
> > > > > drawn.
> > > > 
> > > > I think the correct patch on the gplt_x11.c end is something like the one
> > > > attached here.
> > > 
> > > Fine, it send the ID; however, it does not resend the current one after 
> > > change of the active window:
> > 
> > > gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > > gplt_x11.c:5918: SENDING NEW WINDOWID 0x540008a TO GNUPLOT...
> > > 540008a
> > > gnuplot> set term x11 2; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > > gplt_x11.c:5918: SENDING NEW WINDOWID 0x54000a6 TO GNUPLOT...
> > > 54000a6
> > > gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > > 54000a6
> > 
> > That's exactly what I've been trying to point out all along!
> > Glad we agree :-)
> 
> I'm not so sure whether you also think it is a bug to be fixed, because the 
> ID needs to be sent after each new activation, i.e.
> 
> 	set term x11 1
> 	plot sth ---> now send the ID
> 	plot sth   ... no need to send the ID
> 	plot sth   ... no need to send the ID
> 	plot sth   ... no need to send the ID
> 
> 	set term x11 2
> 	plot sth ---> now send the ID
> 	plot sth   ... no need to send the ID
> 	plot sth   ... no need to send the ID
> 
> 	set term x11 1
> 	plot sth ---> now send the ID
> 	plot sth   ... no need to send the ID
> 	plot sth   ... no need to send the ID
> 
> and your patch does not do that.

It seems that the ID has to be really sent after "set term x11 + plot":

gnuplot> set term x11 1; plot x; system('xwininfo | grep -w id')
Terminal type set to 'x11'
Options are '1 nopersist'
xwininfo: Window id: 0x5e0008a "Gnuplot 1"

gnuplot> set term x11 2; plot x*x; system('xwininfo | grep -w id')
Terminal type set to 'x11'
Options are '2 nopersist'
xwininfo: Window id: 0x5e000a3 "Gnuplot 2"

gnuplot> !killall gnuplot_x11
!
gnuplot> set term x11 2; plot x*x; system('xwininfo | grep -w id')
Terminal type set to 'x11'
Options are '2 nopersist'
xwininfo: Window id: 0x5e0008a "Gnuplot"

---
PM

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

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

On Sat, 7 Feb 2009 pl...@pi... wrote:

> the linux textinfo help has also been criticised recently and I find it
> pretty intractable to use.
>
> Would this be an opportunity to convert the help to one unified,
> cross-platform format?
>
> One obvious possibility is HTML. Although it lacks the nice indexing a
> nd cross referencing facilities of winhelp, it would allow
> linux/macOS/win* plus web documentation in one hit. This would
> presumably be plus for maintainability.

Why would HTML necessarily lack nice indexing and
cross-referencing?

Allin Cottrell

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

[<pl...@pi...>]

Shigeharu TAKENO wrote:
> shige 02/07 2009
> ----------------
> 
> tma...@ya... wrote:
>> I have installed wgnuplot to the PC of one of students in my lab.
>> The OS is windows vista. I found that old type help file used for wgnuplot is
>> not supported on vista
> 
> One solution is to use the following:
> 
> http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb
> http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb&displaylang=ja
> 

HI,

the linux textinfo help has also been criticised recently and I find it
pretty intractable to use.

Would this be an opportunity to convert the help to one unified,
cross-platform format?

One obvious possibility is HTML. Although it lacks the nice indexing a
nd cross referencing facilities of winhelp, it would allow
linux/macOS/win* plus web documentation in one hit. This would
presumably be plus for maintainability.

Re: Current wgnuplot.hlp is obsolate and cannot be opened in windows vista

[Shigeharu T. <sh...@ie...>]

shige 02/07 2009
----------------

tma...@ya... wrote:
> I have installed wgnuplot to the PC of one of students in my lab.
> The OS is windows vista. I found that old type help file used for wgnuplot is
> not supported on vista

One solution is to use the following:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb
http://www.microsoft.com/downloads/details.aspx?FamilyID=6ebcfad9-d3f5-4365-8070-334cd175d4bb&displaylang=ja

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> > > > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > > > > "new window" event from gnuplot_x11, right?  
> > > > > 
> > > > > I am trying to point out that not every command "set term x11 <num>" creates
> > > > > a new window. If an old window is re-used, you won't receive this event and
> > > > > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > > > > 
> > > > > The patch currently has the event generated each time the buffered command
> > > > > list is re-executed, which I think is not right.  Probably it should go in
> > > > > pr_window(), immediately after the call to XCreateWindow().
> > > > 
> > > > When I tested it, it was filling the variable after the "plot" command has 
> > > > been completed (not after "set term x11"), i.e. after the graph has been 
> > > > drawn.
> > > 
> > > I think the correct patch on the gplt_x11.c end is something like the one
> > > attached here.
> > 
> > Fine, it send the ID; however, it does not resend the current one after 
> > change of the active window:
> 
> > gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > gplt_x11.c:5918: SENDING NEW WINDOWID 0x540008a TO GNUPLOT...
> > 540008a
> > gnuplot> set term x11 2; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > gplt_x11.c:5918: SENDING NEW WINDOWID 0x54000a6 TO GNUPLOT...
> > 54000a6
> > gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> > 54000a6
> 
> That's exactly what I've been trying to point out all along!
> Glad we agree :-)

I'm not so sure whether you also think it is a bug to be fixed, because the 
ID needs to be sent after each new activation, i.e.

	set term x11 1
	plot sth ---> now send the ID
	plot sth   ... no need to send the ID
	plot sth   ... no need to send the ID
	plot sth   ... no need to send the ID

	set term x11 2
	plot sth ---> now send the ID
	plot sth   ... no need to send the ID
	plot sth   ... no need to send the ID

	set term x11 1
	plot sth ---> now send the ID
	plot sth   ... no need to send the ID
	plot sth   ... no need to send the ID

and your patch does not do that.

---
PM

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Friday 06 February 2009 15:45:20 Petr Mikulik wrote:
> > On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
> > > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > > > "new window" event from gnuplot_x11, right?  
> > > > 
> > > > I am trying to point out that not every command "set term x11 <num>" creates
> > > > a new window. If an old window is re-used, you won't receive this event and
> > > > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > > > 
> > > > The patch currently has the event generated each time the buffered command
> > > > list is re-executed, which I think is not right.  Probably it should go in
> > > > pr_window(), immediately after the call to XCreateWindow().
> > > 
> > > When I tested it, it was filling the variable after the "plot" command has 
> > > been completed (not after "set term x11"), i.e. after the graph has been 
> > > drawn.
> > 
> > I think the correct patch on the gplt_x11.c end is something like the one
> > attached here.
> 
> Fine, it send the ID; however, it does not resend the current one after 
> change of the active window:

That's exactly what I've been trying to point out all along!
Glad we agree :-)

> gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> gplt_x11.c:5918: SENDING NEW WINDOWID 0x540008a TO GNUPLOT...
> 540008a
> gnuplot> set term x11 2; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> gplt_x11.c:5918: SENDING NEW WINDOWID 0x54000a6 TO GNUPLOT...
> 54000a6
> gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
> 54000a6
> 
> ---
> PM
> 



-- 
Ethan A Merritt

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
> > > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > > "new window" event from gnuplot_x11, right?  
> > > 
> > > I am trying to point out that not every command "set term x11 <num>" creates
> > > a new window. If an old window is re-used, you won't receive this event and
> > > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > > 
> > > The patch currently has the event generated each time the buffered command
> > > list is re-executed, which I think is not right.  Probably it should go in
> > > pr_window(), immediately after the call to XCreateWindow().
> > 
> > When I tested it, it was filling the variable after the "plot" command has 
> > been completed (not after "set term x11"), i.e. after the graph has been 
> > drawn.
> 
> I think the correct patch on the gplt_x11.c end is something like the one
> attached here.

Fine, it send the ID; however, it does not resend the current one after 
change of the active window:

gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
gplt_x11.c:5918: SENDING NEW WINDOWID 0x540008a TO GNUPLOT...
540008a
gnuplot> set term x11 2; test; print sprintf("%x", GPVAL_X11_WINDOWID)
gplt_x11.c:5918: SENDING NEW WINDOWID 0x54000a6 TO GNUPLOT...
54000a6
gnuplot> set term x11 1; test; print sprintf("%x", GPVAL_X11_WINDOWID)
54000a6

---
PM

pause in gnuplot.exe

[Tim H. <tim...@un...>]

Consider the script (run with CVS version)

plot x**2
pause mouse any

plot changes focus to graph window. In wgnuplot.exe the pause command is 
finished on key press even though the graph window is in focus. In 
gnuplot.exe this doesn't work. I have to set focus back to the console 
window before pause can be ended.

"pause <time>" times out as it should. But "pause -1" and all "pause 
mouse" commands require manually switching back to the console.


I also noticed that plot changes the focus to the graph window only when 
gnuplot.exe is called with a scriptfile. In interactive operation the 
focus stays on the the console window. Is this different behaviour intended?

Tim

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
> > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > "new window" event from gnuplot_x11, right?  
> > 
> > I am trying to point out that not every command "set term x11 <num>" creates
> > a new window. If an old window is re-used, you won't receive this event and
> > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > 
> > The patch currently has the event generated each time the buffered command
> > list is re-executed, which I think is not right.  Probably it should go in
> > pr_window(), immediately after the call to XCreateWindow().
> 
> When I tested it, it was filling the variable after the "plot" command has 
> been completed (not after "set term x11"), i.e. after the graph has been 
> drawn.

I think the correct patch on the gplt_x11.c end is something like the one
attached here.

-- 
Ethan A Merritt

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Friday 06 February 2009 13:57:41 Petr Mikulik wrote:
> > The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> > "new window" event from gnuplot_x11, right?  
> > 
> > I am trying to point out that not every command "set term x11 <num>" creates
> > a new window. If an old window is re-used, you won't receive this event and
> > therefore GPVAL_TERM_WINDOWID  will not be updated.
> > 
> > The patch currently has the event generated each time the buffered command
> > list is re-executed, which I think is not right.  Probably it should go in
> > pr_window(), immediately after the call to XCreateWindow().
> 
> When I tested it, it was filling the variable after the "plot" command has 
> been completed (not after "set term x11"), i.e. after the graph has been 
> drawn.

Yes, exactly.  Therefore it is not correct.  Try rotating a 3D plot and
you will see that it is trying to re-evaluate and re-send the window id
on every refresh.  This slows things down impossibly.

-- 
Ethan A Merritt

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
> "new window" event from gnuplot_x11, right?  
> 
> I am trying to point out that not every command "set term x11 <num>" creates
> a new window. If an old window is re-used, you won't receive this event and
> therefore GPVAL_TERM_WINDOWID  will not be updated.
> 
> The patch currently has the event generated each time the buffered command
> list is re-executed, which I think is not right.  Probably it should go in
> pr_window(), immediately after the call to XCreateWindow().

When I tested it, it was filling the variable after the "plot" command has 
been completed (not after "set term x11"), i.e. after the graph has been 
drawn.

Petr

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Friday, February 06, 2009, at 04:27PM, "Petr Mikulik" <mi...@ph...> wrote:
>> >It does update the GPVAL_TERM_WINDOWID variable, please try the proposed 
>> >patch.
>> >
>> I've build gnuplot with the current sources and with your patch applied.
>> 
>> Terminal type set to 'x11'
>> gnuplot> plot sin(x)
>> gnuplot> gplt_x11.c:1528: SENDING MY WINDOWID TO GNUPLOT...
>> mouse.c:1854: set current_x11_windowid to 12345
>> 
>> When I try a "show all" I do not see any variables that look like 
>> GPVAL_TERM_WINDOWID. In fact, I don't see any variables beginning with 
>> "GPVAL_...".
>
>Use
>	show var all
>
>Petr

ok. Thanks

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> >It does update the GPVAL_TERM_WINDOWID variable, please try the proposed 
> >patch.
> >
> I've build gnuplot with the current sources and with your patch applied.
> 
> Terminal type set to 'x11'
> gnuplot> plot sin(x)
> gnuplot> gplt_x11.c:1528: SENDING MY WINDOWID TO GNUPLOT...
> mouse.c:1854: set current_x11_windowid to 12345
> 
> When I try a "show all" I do not see any variables that look like 
> GPVAL_TERM_WINDOWID. In fact, I don't see any variables beginning with 
> "GPVAL_...".

Use
	show var all

Petr

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

[Ben A. <bpa...@ma...>]

On Friday, February 06, 2009, at 12:38PM, "Petr Mikulik" <mi...@ph...> wrote:
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
>> [ 2570385 ] GPVAL_X11_WINDOWID
>>
>> > > 3. New global variable current_x11_windowid should be placed in an .h + .c 
>> > >    file. Which one?
>> > 
>> > > That will probably not work.  There can be multiple x11 windows open at 
>> > > the same time, so there is no "current" one.  Since you can associate a 
>> > > window number with each one, however, we might be able to do:
>> > >       set term x11 5
>> > >       print TERM_X11_WINDOW_5_ID 
>> > 
>> > The current one is the current active one. It is the last one from "set term 
>> > x11". The value of GPVAL_TERM_WINDOWID is to be used by a front-end (such as 
>> > Octave) using gnuplot for drawings; thus, it can fetch the Window ID just 
>> > after the plot command.
>> 
>> But "set term x11 5" will not necessarily open a new window; it will re-use
>> the old window #5 if there is one.  So it will not necessarily trigger a
>> window creation event, and thus would not automatically update your proposed
>> *_CURRENT_* variable.  I suppose the terminal driver could maintain a list
>> of previously-created window ids.
>
>It does update the GPVAL_TERM_WINDOWID variable, please try the proposed 
>patch.
>

Petr,

I've build gnuplot with the current sources and with your patch applied.

Terminal type set to 'x11'
gnuplot> plot sin(x)
gnuplot> gplt_x11.c:1528: SENDING MY WINDOWID TO GNUPLOT...
mouse.c:1854: set current_x11_windowid to 12345

When I try a "show all" I do not see any variables that look like GPVAL_TERM_WINDOWID. In fact, I don't see any variables beginning with "GPVAL_...". 

I'm obvioulsy missing something.

Ben

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Friday 06 February 2009 09:38:10 Petr Mikulik wrote:
> > https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
> > [ 2570385 ] GPVAL_X11_WINDOWID
> >
> > > > 3. New global variable current_x11_windowid should be placed in an .h + .c 
> > > >    file. Which one?
> > > 
> > > > That will probably not work.  There can be multiple x11 windows open at 
> > > > the same time, so there is no "current" one.  Since you can associate a 
> > > > window number with each one, however, we might be able to do:
> > > >       set term x11 5
> > > >       print TERM_X11_WINDOW_5_ID 
> > > 
> > > The current one is the current active one. It is the last one from "set term 
> > > x11". The value of GPVAL_TERM_WINDOWID is to be used by a front-end (such as 
> > > Octave) using gnuplot for drawings; thus, it can fetch the Window ID just 
> > > after the plot command.
> > 
> > But "set term x11 5" will not necessarily open a new window; it will re-use
> > the old window #5 if there is one.  So it will not necessarily trigger a
> > window creation event, and thus would not automatically update your proposed
> > *_CURRENT_* variable.  I suppose the terminal driver could maintain a list
> > of previously-created window ids.
> 
> It does update the GPVAL_TERM_WINDOWID variable, please try the proposed 
> patch.

The intent is to update GPVAL_TERM_WINDOWID when the main program receives a
"new window" event from gnuplot_x11, right?  

I am trying to point out that not every command "set term x11 <num>" creates
a new window. If an old window is re-used, you won't receive this event and
therefore GPVAL_TERM_WINDOWID  will not be updated.

The patch currently has the event generated each time the buffered command
list is re-executed, which I think is not right.  Probably it should go in
pr_window(), immediately after the call to XCreateWindow().

-- 
Ethan A Merritt

Re: if (1) b="plot x*x"; @b

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

> > There is a strange error happening with a not-yet-used variable:
> > 
> > gnuplot> load 'bug.gp'
> >          "bug.gp", line 4: warning: b is not a string variable
> > 
> > where bug.gp:
> > 
> > set macros
> > a=''
> > if (1) a="plot x"; @a
> > if (1) b="plot x*x"; @b
> 
> This has always been a limitation on the use of macros.
> The substitution is done for each whole line as the line
> is read in, before any of the commands on that line have
> been executed.  

I see; a better demonstration of this effect it rather this one:

set macros
a='print 789'
if (1) a="print 123"; @a
if (1) b="print 456"; @b

The solution seems to be:

set macros
if (1) b="print 999"
if (1) @b


> For most purposes, the use of macros has been entirely supplanted
> by string variables. In the case above:
> 
>  if (1) a="plot x";  evaluate(a)

Thanks for this hint, it works fine in gnuplot-cvs.
Finally I had to use the construct with macros because the script had to run 
on gnuplot 4.2.x.

---
PM

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
> [ 2570385 ] GPVAL_X11_WINDOWID
>
> > > 3. New global variable current_x11_windowid should be placed in an .h + .c 
> > >    file. Which one?
> > 
> > > That will probably not work.  There can be multiple x11 windows open at 
> > > the same time, so there is no "current" one.  Since you can associate a 
> > > window number with each one, however, we might be able to do:
> > >       set term x11 5
> > >       print TERM_X11_WINDOW_5_ID 
> > 
> > The current one is the current active one. It is the last one from "set term 
> > x11". The value of GPVAL_TERM_WINDOWID is to be used by a front-end (such as 
> > Octave) using gnuplot for drawings; thus, it can fetch the Window ID just 
> > after the plot command.
> 
> But "set term x11 5" will not necessarily open a new window; it will re-use
> the old window #5 if there is one.  So it will not necessarily trigger a
> window creation event, and thus would not automatically update your proposed
> *_CURRENT_* variable.  I suppose the terminal driver could maintain a list
> of previously-created window ids.

It does update the GPVAL_TERM_WINDOWID variable, please try the proposed 
patch.

---
PM

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

On Friday 06 February 2009 00:45:40 Petr Mikulik wrote:

> > 3. New global variable current_x11_windowid should be placed in an .h + .c 
> >    file. Which one?
> 
> > That will probably not work.  There can be multiple x11 windows open at 
> > the same time, so there is no "current" one.  Since you can associate a 
> > window number with each one, however, we might be able to do:
> >       set term x11 5
> >       print TERM_X11_WINDOW_5_ID 
> 
> The current one is the current active one. It is the last one from "set term 
> x11". The value of GPVAL_TERM_WINDOWID is to be used by a front-end (such as 
> Octave) using gnuplot for drawings; thus, it can fetch the Window ID just 
> after the plot command.

But "set term x11 5" will not necessarily open a new window; it will re-use
the old window #5 if there is one.  So it will not necessarily trigger a
window creation event, and thus would not automatically update your proposed
*_CURRENT_* variable.  I suppose the terminal driver could maintain a list
of previously-created window ids.

-- 
Ethan A Merritt

Re: if (1) b="plot x*x"; @b

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

On Friday 06 February 2009, Petr Mikulik wrote:
> There is a strange error happening with a not-yet-used variable:
> 
> gnuplot> load 'bug.gp'
>          "bug.gp", line 4: warning: b is not a string variable
> 
> where bug.gp:
> 
> set macros
> a=''
> if (1) a="plot x"; @a
> if (1) b="plot x*x"; @b

This has always been a limitation on the use of macros.
The substitution is done for each whole line as the line
is read in, before any of the commands on that line have
been executed.  

For most purposes, the use of macros has been entirely supplanted
by string variables. In the case above:

 if (1) a="plot x";  evaluate(a);



-- 
Ethan A Merritt

Re: if (1) b="plot x*x"; @b

[Thomas S. <t.s...@fz...>]

it's a timing problem, with 'set term x11' nothing is plotted
for 'a' (because 'a' is empty when '@a' is executed),
a second '@a' typed in at the prompt results in a plot.
the same applies to 'b'.


Petr Mikulik wrote:
> 
> There is a strange error happening with a not-yet-used variable:
> 
> gnuplot> load 'bug.gp'
>          "bug.gp", line 4: warning: b is not a string variable
> 
> where bug.gp:
> 
> set macros
> a=''
> if (1) a="plot x"; @a
> if (1) b="plot x*x"; @b
> 
> ---
> PM
> 
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code
> to
> build responsive, highly engaging applications that combine the power of
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/if-%281%29-b%3D%22plot-x*x%22--%40b-tp21871348p21875202.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

if (1) b="plot x*x"; @b

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

There is a strange error happening with a not-yet-used variable:

gnuplot> load 'bug.gp'
         "bug.gp", line 4: warning: b is not a string variable

where bug.gp:

set macros
a=''
if (1) a="plot x"; @a
if (1) b="plot x*x"; @b

---
PM

Re: problem with "set x11 {size WW,HH} {position XX,YY}"

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

> https://sourceforge.net/tracker/index.php?func=detail&aid=2570385&group_id=2055&atid=302055
> [ 2570385 ] GPVAL_X11_WINDOWID

I will have a look.

> 3. New global variable current_x11_windowid should be placed in an .h + .c 
>    file. Which one?

> That will probably not work.  There can be multiple x11 windows open at 
> the same time, so there is no "current" one.  Since you can associate a 
> window number with each one, however, we might be able to do:
>       set term x11 5
>       print TERM_X11_WINDOW_5_ID 

The current one is the current active one. It is the last one from "set term 
x11". The value of GPVAL_TERM_WINDOWID is to be used by a front-end (such as 
Octave) using gnuplot for drawings; thus, it can fetch the Window ID just 
after the plot command.

> 4. Should it be called GPVAL_TERM_WINDOWID or GPVAL_X11_WINDOWID ? The wxt 
>    terminal can run not only under X11, but e.g. under windows as well. Is 
>    there something like window id?
>
>       TERM_something

Note there is already GPVAL_TERM. As all automatic variables are prefixed 
GPVAL_ (except for MOUSE_), the new one should become GPVAL_TERM_WINDOWID.

---
PM