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

Re: Revised SVG terminal supports mouse interaction

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, April 10, 2011, Mojca Miklavec wrote:
> On Sun, Apr 10, 2011 at 18:26, sfeam (Ethan Merritt) wrote:
> > On Sunday, April 10, 2011, Mojca Miklavec wrote:
> 
> It seems that *is* a browser problem then. It works fine in Chrome,
> but on Safari only the line disapears and the points stay.

For me Chrome doesn't work at all.  It displays only a banner
"Missing Plugin".  But the Google documentation on plugins seems
to say that it is really a methods limitation rather than a 
plugin issue.  I.e., if you manually replace <embed src="foo.svg">
with <img src="foo.svg"> then it displays statically but is not
interactive.

So the bottom line is still that SVG support in the various browsers
is unreliable.

Does Safari have a javascript error console?  If so, you might 
find a message that hints at the cause of the lines/points problem.
If there is some particular construct or sequence of elements that
it doesn't like, perhaps we could find a work-around.

	Ethan

> 
> >   http://gnuplot.sourceforge.net/demo_svg_4.5/dashcolor.html
> 
> In this example I cannot convince the Safari browser to hide anything
> at all. And points behave weird even in Chrome (when I click on line
> to hide it, the line over the point in legend is redrawn, so clicking
> also toggles the line segment crossing empty square - "pi -3" for
> example).
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Revised SVG terminal supports mouse interaction

[Mojca M. <moj...@gm...>]

On Sun, Apr 10, 2011 at 18:26, sfeam (Ethan Merritt) wrote:
> On Sunday, April 10, 2011, Mojca Miklavec wrote:
>>
>> I have only discovered one weirdness. With linespoints clicking on the
>> label only removes the line, not the points of the same plot, but I
>> guess that this is not Safari-specific.
>
> Huh. I did not see that in any of my testing.
> Could you please recheck this for the "with lp" variants used in
> these demos:
>
>   http://gnuplot.sourceforge.net/demo_svg_4.5/running_avg.html

That was exactly the example I was testing.

It seems that *is* a browser problem then. It works fine in Chrome,
but on Safari only the line disapears and the points stay.

>   http://gnuplot.sourceforge.net/demo_svg_4.5/dashcolor.html

In this example I cannot convince the Safari browser to hide anything
at all. And points behave weird even in Chrome (when I click on line
to hide it, the line over the point in legend is redrawn, so clicking
also toggles the line segment crossing empty square - "pi -3" for
example).

Mojca

Re: Revised SVG terminal supports mouse interaction

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

On 10.04.2011 11:02, Mojca Miklavec wrote:

> I have only discovered one weirdness. With linespoints clicking on the
> label only removes the line, not the points of the same plot, but I
> guess that this is not Safari-specific.

Sure those were actual linespoints, as opposed to something like

	plot 'foo' w lines, '' w p

?  This is a (probably unavoidable) shortcoming of this technique: 
datasets without a key entry can't be influenced by it.

Re: Revised SVG terminal supports mouse interaction

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, April 10, 2011, Mojca Miklavec wrote:
> On Sun, Apr 10, 2011 at 05:06, sfeam (Ethan Merritt)
> <eam...@gm...> wrote:
> > I have dusted off various patches, comments and suggestions uploaded
> > to SourceForge dating back 2 years or so, and with their guidance
> > have managed to write a set of javascript support routines for the
> > SVG terminal driver.  Since I am largely unfamiliar with both SVG and
> > javascript, this implementation should be considered fair game for
> > total replacement if someone more knowledgeable wants to tackle the
> > project.
> >
> 
> I have only discovered one weirdness. With linespoints clicking on the
> label only removes the line, not the points of the same plot, but I
> guess that this is not Safari-specific.

Huh. I did not see that in any of my testing.
Could you please recheck this for the "with lp" variants used in
these demos:

   http://gnuplot.sourceforge.net/demo_svg_4.5/running_avg.html
   http://gnuplot.sourceforge.net/demo_svg_4.5/dashcolor.html

	thanks,

		Ethan


> 
> Mojca
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Revised SVG terminal supports mouse interaction

[Mojca M. <moj...@gm...>]

On Sun, Apr 10, 2011 at 05:06, sfeam (Ethan Merritt)
<eam...@gm...> wrote:
> I have dusted off various patches, comments and suggestions uploaded
> to SourceForge dating back 2 years or so, and with their guidance
> have managed to write a set of javascript support routines for the
> SVG terminal driver.  Since I am largely unfamiliar with both SVG and
> javascript, this implementation should be considered fair game for
> total replacement if someone more knowledgeable wants to tackle the
> project.
>
> SVG documents from the revised driver can now
>   - toggle display of individual plots by clicking on the
>     corresponding legend or sample in the key
>   - toggle the grid on/off by clicking on a grid icon shown
>     at the bottom left of the plot
>   - track the mouse position
>
> A regenerated set of online demo pages may be viewed at
>
>  http://gnuplot.sourceforge.net/demo_svg_4.5/
>
> Not surprisingly, SVG support in various web browsers and
> graphics programs is still dodgy.
>
> Firefox (tested using version 3.6.14)
>  - Firefox can display and interact with the bare SVG document
>  or an HTML document with SVG embedded (e.g. the online demos)
>  - It has various rendering bugs, the most annoying of which is
>  that it ignores purely vertical lines.  Because of this I have
>  added an ugly hack to svg.trm to displace one end of every
>  Path element by 0.01 pixel horizontally.
>
> Opera (tested using version 11.01)
>  - Everything works
>
> Konqueror (tested using version 4.4.3)
>  - Konqueror displays isolated or embedded SVG documents correctly
>  but fails to connect to the javascript DOM so that you can
>  interact with it.
>  - No support for pattern fill
>
> Chrome
>  - Chrome displays isolated SVG documents correctly, but fails to
>  display embedded documents.  No interaction.
>
> I'd like to hear about success/failure with Safari or IE.

It seems to work fine in Safari.

It takes ages to draw something like
http://gnuplot.sourceforge.net/demo_svg_4.5/transparent_solids.html.
No, wait. That was not SVG's fault. I have only now realized that the
generated graphics are approximately 1 MB and it only took ages do
download them.

I have only discovered one weirdness. With linespoints clicking on the
label only removes the line, not the points of the same plot, but I
guess that this is not Safari-specific.

Mojca

Revised SVG terminal supports mouse interaction

[sfeam (E. Merritt) <eam...@gm...>]

I have dusted off various patches, comments and suggestions uploaded
to SourceForge dating back 2 years or so, and with their guidance
have managed to write a set of javascript support routines for the 
SVG terminal driver.  Since I am largely unfamiliar with both SVG and
javascript, this implementation should be considered fair game for
total replacement if someone more knowledgeable wants to tackle the
project.

SVG documents from the revised driver can now
   - toggle display of individual plots by clicking on the
     corresponding legend or sample in the key
   - toggle the grid on/off by clicking on a grid icon shown
     at the bottom left of the plot
   - track the mouse position

A regenerated set of online demo pages may be viewed at

  http://gnuplot.sourceforge.net/demo_svg_4.5/

Not surprisingly, SVG support in various web browsers and 
graphics programs is still dodgy.  

Firefox (tested using version 3.6.14)
  - Firefox can display and interact with the bare SVG document
  or an HTML document with SVG embedded (e.g. the online demos)
  - It has various rendering bugs, the most annoying of which is
  that it ignores purely vertical lines.  Because of this I have
  added an ugly hack to svg.trm to displace one end of every
  Path element by 0.01 pixel horizontally.

Opera (tested using version 11.01)
  - Everything works

Konqueror (tested using version 4.4.3)
  - Konqueror displays isolated or embedded SVG documents correctly
  but fails to connect to the javascript DOM so that you can
  interact with it.
  - No support for pattern fill

Chrome
  - Chrome displays isolated SVG documents correctly, but fails to
  display embedded documents.  No interaction.   

I'd like to hear about success/failure with Safari or IE.

	cheers,

		Ethan

Re: GNUplot "not responding" Windows 7 fix!!!

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

Hello

In addtion to the cairo base terminals (pngcairo, pdfcairo and wxt),  the gd based terminals (png, gif
and jpeg) based terminals are linked to the fontconfig libraries.

Please see the note on the page 

**************************
On 2009-12-03, it is found that 'bin' directory (folder) is special directry when executables
(wgnuplot.exe, gnuplot.exe, ...) are saved there. Now the directory name where the executables are
saved is 'binary'. The directory 'bin' is usually used for directory structure in unix softwares. I
appreciate Petr Mikulik for his indication. 

If the excutable are saved in the 'bin' directory, one should move all contents in binary/share and
binary/etc in current distribution to move to bin/../share and bin/../etc (i.e. the 'share' and 'etc'
directories should be placed in the same hierarchy as the 'bin' directory). 

This special treatment for 'bin' directry is useful for if you use gnuplot installing into softwares
which have unixy directory structures, for example, GNU octave.
*******************

Regards

Tatsuro
--- Tatsuro MATSUOKA wrote:

> Hello
> 
> I am building binaries windows 7 home premium 64bit.
> I cannot reproduce the phenomena on my PC.
> (I do not install them in the 'C:\Program Files' but in the different named folder.)
> 
> 
> If you rename 'binary' to 'bin', the procedure will cause fontconfig error on cairo based
> terminals. 
> In the case, please move bin/etc folder in the same hierarchy as 'bin'.
> 
> Regards
> 
> Tatsuro 
> 
> --- Victor Jenicek  wrote:
> 
> > Hi Tatsuro!!
> > 
> > I've been seeing your forum posts quite frequently this afternoon 
> > because I tried getting GNUplot to work on a Windows 7 32-bit 
> > Professional machine.
> > 
> > First I tried the latest installers from SourceForge and then I 
> > downloaded your gp45-winbin.zip. I always extracted the gnuplot folder 
> > to C:\Program Files , and it never worked... the problem was always the 
> > same: after launching wgnuplot.exe or gnuplot.exe and inputting command 
> > plot sin(x), the plot window launches but then the program stops 
> > responding, even after 1-2 minutes of waiting.
> > 
> > But I found a fix on some forum for Octave!
> > 
> > If you rename the "binary" folder in "gnuplot" folder to "bin", it 
> > works!! The function sin(x) is plotted successfully, and I tried some 
> > other functions, like sin(x)/x, and it works too!
> > 
> > I haven't tried this fix with the latest gnuplot version from 
> > Sourceforge, but I thought I should bring this to your attention anyway.
> > 
> > Cheers
> > Victor
> > 
> 
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: GNUplot "not responding" Windows 7 fix!!!

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

Hello

I am building binaries windows 7 home premium 64bit.
I cannot reproduce the phenomena on my PC.
(I do not install them in the 'C:\Program Files' but in the different named folder.)


If you rename 'binary' to 'bin', the procedure will cause fontconfig error on cairo based terminals. 
In the case, please move bin/etc folder in the same hierarchy as 'bin'.

Regards

Tatsuro 

--- Victor Jenicek  wrote:

> Hi Tatsuro!!
> 
> I've been seeing your forum posts quite frequently this afternoon 
> because I tried getting GNUplot to work on a Windows 7 32-bit 
> Professional machine.
> 
> First I tried the latest installers from SourceForge and then I 
> downloaded your gp45-winbin.zip. I always extracted the gnuplot folder 
> to C:\Program Files , and it never worked... the problem was always the 
> same: after launching wgnuplot.exe or gnuplot.exe and inputting command 
> plot sin(x), the plot window launches but then the program stops 
> responding, even after 1-2 minutes of waiting.
> 
> But I found a fix on some forum for Octave!
> 
> If you rename the "binary" folder in "gnuplot" folder to "bin", it 
> works!! The function sin(x) is plotted successfully, and I tried some 
> other functions, like sin(x)/x, and it works too!
> 
> I haven't tried this fix with the latest gnuplot version from 
> Sourceforge, but I thought I should bring this to your attention anyway.
> 
> Cheers
> Victor
> 

Re: array variables?

[Ethan A M. <sf...@us...>]

On Wednesday, April 06, 2011 06:05:23 am pl...@pi... wrote:
> Hi,
> 
> I have to plot some data that depend on a parameter (pump speed) that I 
> read in with each line of data. I need to calculate a plot value 
> dependant on this value. I had it parametised as a function I call form 
> the plot command but this is not accurate enough. I need it to be a 
> look-up table (ie array) of values.
> 
> flo(dac)=flo_grad*(dac-16)+flo_0;
> 
> this needs to be
> 
> flo(dac)=speed[n];
> 
> now am I missing a trick or is this simply not possible with the kind of 
> algebra available within a gnuplot script?

Not currently supported.
The closest we have is

  speed = " 1.11 2.22 3.33 4.44 5.55 "
  flo = word(speed,n)

Re: Explicit color for pm3d

[Daniel J S. <dan...@ie...>]

Douglas,

Could you create an example of what you have in mind using gnuplot with 
external data?  E.g., take some sample data to create a normal shading. 
  Then compute the gradients with some other program and create another 
plot for that data.  All we would need is the two data sets and the 
commands to create the plots.

Dan


On 04/06/2011 05:06 PM, Douglas Mason wrote:
> I'm clearly unlearned in this field!
>
> However, I do believe this approach would allow gnuplot to accomplish flat
> shading (http://en.wikipedia.org/wiki/Phong_shading). Flat shading is more
> than enough for bump maps when the resolution of the input data is high
> enough, or interpolated sufficiently.
>
> I love the simplicity and specificity of gnuplot, and would never ask that
> it become some virtual reality rendering tool. However, bump maps are
> exceedingly useful in certain applications, for instance when conveying
> terrain or a potential surface (I can share a paper), so having complete
> control over both the color height function and the lighting (i.e., angle
> and harshness) would be prized. In these applications, the resolution of the
> input data is usually greater than what you actually plot.
>
> If you have any more input it would be greatly appreciated!
>
> On Wed, Apr 6, 2011 at 5:34 PM, Ethan A Merritt<sf...@us...
>> wrote:
>
>> Douglas Mason<dou...@gm...>  wrote>
>>>
>>> Let's say you have a surface. It should be trivial to calculate the
>> gradient
>>> at any point in the surface by simply calculating the difference to each
>>> neighboring point.
>>
>> Not exactly trivial, but yes it could be done.
>>
>>> Based on the technique of normal maps, you can create a function that
>> simply
>>> adds or subtracts light (i.e., each RGB channel in unison) based on the
>>> angle of the gradient. Or simply provide said normal map which has its
>> own
>>> uses.
>>
>> I take it you are thinking of Gouraud shading, but that's not how it works.
>> The normal at each vertex is used to calculate a different shading at each
>> pixel within the face bounded by those vertices.  But gnuplot cannot draw
>> pixel-by-pixel; it draws the entiry face in one go.  So differential
>> shading
>> across the face is not possible.
>>
>>> This would permit a perfectly usable bump map in gnuplot
>>
>> A bump map is something else again.  But again this results in a per-pixel
>> color distinction.  So - nice idea, but not in gnuplot.
>>
>>         Ethan
>>
>


-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Explicit color for pm3d

[Douglas M. <dou...@gm...>]

I'm clearly unlearned in this field!

However, I do believe this approach would allow gnuplot to accomplish flat
shading (http://en.wikipedia.org/wiki/Phong_shading). Flat shading is more
than enough for bump maps when the resolution of the input data is high
enough, or interpolated sufficiently.

I love the simplicity and specificity of gnuplot, and would never ask that
it become some virtual reality rendering tool. However, bump maps are
exceedingly useful in certain applications, for instance when conveying
terrain or a potential surface (I can share a paper), so having complete
control over both the color height function and the lighting (i.e., angle
and harshness) would be prized. In these applications, the resolution of the
input data is usually greater than what you actually plot.

If you have any more input it would be greatly appreciated!

On Wed, Apr 6, 2011 at 5:34 PM, Ethan A Merritt <sf...@us...
> wrote:

> Douglas Mason <dou...@gm...> wrote>
> >
> > Let's say you have a surface. It should be trivial to calculate the
> gradient
> > at any point in the surface by simply calculating the difference to each
> > neighboring point.
>
> Not exactly trivial, but yes it could be done.
>
> > Based on the technique of normal maps, you can create a function that
> simply
> > adds or subtracts light (i.e., each RGB channel in unison) based on the
> > angle of the gradient. Or simply provide said normal map which has its
> own
> > uses.
>
> I take it you are thinking of Gouraud shading, but that's not how it works.
> The normal at each vertex is used to calculate a different shading at each
> pixel within the face bounded by those vertices.  But gnuplot cannot draw
> pixel-by-pixel; it draws the entiry face in one go.  So differential
> shading
> across the face is not possible.
>
> > This would permit a perfectly usable bump map in gnuplot
>
> A bump map is something else again.  But again this results in a per-pixel
> color distinction.  So - nice idea, but not in gnuplot.
>
>        Ethan
>

Re: Explicit color for pm3d

[Ethan A M. <sf...@us...>]

Douglas Mason <dou...@gm...> wrote>
> 
> Let's say you have a surface. It should be trivial to calculate the gradient
> at any point in the surface by simply calculating the difference to each
> neighboring point.

Not exactly trivial, but yes it could be done.

> Based on the technique of normal maps, you can create a function that simply
> adds or subtracts light (i.e., each RGB channel in unison) based on the
> angle of the gradient. Or simply provide said normal map which has its own
> uses.

I take it you are thinking of Gouraud shading, but that's not how it works.
The normal at each vertex is used to calculate a different shading at each
pixel within the face bounded by those vertices.  But gnuplot cannot draw
pixel-by-pixel; it draws the entiry face in one go.  So differential shading
across the face is not possible.

> This would permit a perfectly usable bump map in gnuplot

A bump map is something else again.  But again this results in a per-pixel
color distinction.  So - nice idea, but not in gnuplot.

	Ethan

Re: Explicit color for pm3d

[Douglas M. <dou...@gm...>]

One item that just occurred to me makes this method extremely versatile.

Let's say you have a surface. It should be trivial to calculate the gradient
at any point in the surface by simply calculating the difference to each
neighboring point. (I wonder if gnuplot could provide this functionality
built in or through a clever trick so it can operate with dgrid3d).

Based on the technique of normal maps, you can create a function that simply
adds or subtracts light (i.e., each RGB channel in unison) based on the
angle of the gradient. Or simply provide said normal map which has its own
uses.

This would permit a perfectly usable bump map in gnuplot, without having to
invoke openGL or hellish programming hurdles for the developers. It cannot
provide shadows, but I wonder if that's even a good idea anyways.

What do you think?

Douglas

On Mon, Mar 28, 2011 at 8:42 PM, Daniel J Sebald <dan...@ie...>wrote:

> On 03/28/2011 12:40 PM, Ethan A Merritt wrote:
>
> > What you're describing is more like a texture map.
> > Input a NxM pixmap, distort/project it onto a surface defined
> > by an explicit function or coarse sampling.
>
> Yes, like a relief map of some sort.
>
> Dan
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: array variables?

[Bastian M. <bm...@ph...>]

Hello,

you might want to experiment with the following functions:

getArray(name, index) = value(sprintf("%s_%i", name, index))
setArray(name, index, value) = sprintf("%s_%i = %f", name, index, value)

Usage would be like this:

 > eval setArray("speed", n, val)
 > flo(n) = getArray("speed", n)

Maybe a function "evaluate()" to accompany the "eval" command would
be a worthwhile addition.

   Bastian

Am 06.04.2011 15:05, schrieb pl...@pi...:
> Hi,
>
> I have to plot some data that depend on a parameter (pump speed) that I
> read in with each line of data. I need to calculate a plot value
> dependant on this value. I had it parametised as a function I call form
> the plot command but this is not accurate enough. I need it to be a
> look-up table (ie array) of values.
>
> flo(dac)=flo_grad*(dac-16)+flo_0;
>
> this needs to be
>
> flo(dac)=speed[n];
>
> I know use of variables is somewhat limited in gnuplot and I can't find
> any documentation that seems relevant. (array keyword referring to input
> format)
>
> I have 16 values so a whole stack of 'if's would be pretty messy.
>
> now am I missing a trick or is this simply not possible with the kind of
> algebra available within a gnuplot script?
>
>
> best regards. Peter.

array variables?

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

Hi,

I have to plot some data that depend on a parameter (pump speed) that I 
read in with each line of data. I need to calculate a plot value 
dependant on this value. I had it parametised as a function I call form 
the plot command but this is not accurate enough. I need it to be a 
look-up table (ie array) of values.

flo(dac)=flo_grad*(dac-16)+flo_0;

this needs to be

flo(dac)=speed[n];

I know use of variables is somewhat limited in gnuplot and I can't find 
any documentation that seems relevant. (array keyword referring to input 
format)

I have 16 values so a whole stack of 'if's would be pretty messy.

now am I missing a trick or is this simply not possible with the kind of 
algebra available within a gnuplot script?


best regards. Peter.

Re: macro bug?

[Arun P. <ape...@lb...>]

Hi

On 03/31/2011 10:04 PM, sfeam (Ethan Merritt) wrote:
> On Thursday, March 31, 2011, Arun Persaud wrote:
>> [...]
>> A=f("t1")
>> B=f("t2")
>>
>> plot @A,g(x),@B,g(x)
>>
>> without using macros?
> 
> I'm not clear on the significance of using A and B
> as opposed to directly calling f().

hmm, f() is just a string that needs to be evaluated and eval f(...)
didn't work inside the plot commando, so I used the macro...

> Is the variant
> below useful? 
> 
>   f(var) = value(var . "_m")
>   g(x) = m*x
>   
>   plot m=f("t1"),g(x), m=f("t2"),g(x)

yes very useful :) I wasn't aware of the value-function, that's exactly
what I tried to accomplish with the macros.

Again: thanks for the fast response!

Arun

Re: macro bug?

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, March 31, 2011, Arun Persaud wrote:
> 
> is there a way then that I can do things like
> 
> set macros
> f(s)=sprintf("m=%s_m",s)
> g(x)=m*x
> 
> t1_m = 1.0
> t2_m = 2.0
> 
> A=f("t1")
> B=f("t2")
> 
> plot @A,g(x),@B,g(x)
> 
> without using macros?

I'm not clear on the significance of using A and B
as opposed to directly calling f().  Is the variant
below useful? 

  f(var) = value(var . "_m")
  g(x) = m*x
  
  plot m=f("t1"),g(x), m=f("t2"),g(x)


> Here is some addition for the manual (output of cvs diff -u)

Thanks.
 
> -----------------start-------------------------------
> 
> RCS file: /cvsroot/gnuplot/gnuplot/docs/gnuplot.doc,v
> retrieving revision 1.658
> diff -u -r1.658 gnuplot.doc
> --- gnuplot.doc	26 Mar 2011 02:39:44 -0000	1.658
> +++ gnuplot.doc	1 Apr 2011 04:07:32 -0000
> @@ -2584,6 +2584,18 @@
>   Macro expansion does not occur inside either single or double quotes.
>   However macro expansion does occur inside backquotes.
> 
> + Macro expansion is also handled as the very first thing the
> + interpreter does when looking at a new line of commands and is only
> + done once. Therefore, code like the following will execute correctly:
> +
> +      A = "c=1"
> +      @A
> +
> + but this line will not, since the macro is defined on the same line
> + and can't be expanded in time
> +
> +      A = "c=1"; @A   # will not expand to c=1
> +
>   For execution of complete commands the `evaluate` command may also be
> handy.
>  3 String variables, macros, and command line substitution
>  ?mixing_macros_backquotes
> 
> -------------------end----------------------
> 
> Thanks for the quick help
> 
> Arun
>
> 

Re: macro bug?

[Arun P. <ape...@lb...>]

Hi

On 03/31/2011 07:50 PM, sfeam (Ethan Merritt) wrote:
>[...]
> The macro mechanism was a first attempt at string handling.
> It didn't really work out all that well.
> Proper string handling replaced it for most purposes,

is there a way then that I can do things like

set macros
f(s)=sprintf("m=%s_m",s)
g(x)=m*x

t1_m = 1.0
t2_m = 2.0

A=f("t1")
B=f("t2")

plot @A,g(x),@B,g(x)

without using macros?

> and perhaps
> the macro stuff should have been removed, but we're such sticklers
> for backwards compatibility that it's still there.
> 
> Anyhow...
> The problem you're seeing is inherent in the way that the macros work.
> They are applied line-by-line to the input stream, as the very first
> thing before the line is actually interpreted or executed.
> But that means if you define a new macro on a particular line,
> that line has already been through the macro substitution process
> and substitutions involving the new macro cannot take effect until
> the next line.

Thanks for the explanation, makes sense...

Here is some addition for the manual (output of cvs diff -u)

-----------------start-------------------------------

RCS file: /cvsroot/gnuplot/gnuplot/docs/gnuplot.doc,v
retrieving revision 1.658
diff -u -r1.658 gnuplot.doc
--- gnuplot.doc	26 Mar 2011 02:39:44 -0000	1.658
+++ gnuplot.doc	1 Apr 2011 04:07:32 -0000
@@ -2584,6 +2584,18 @@
  Macro expansion does not occur inside either single or double quotes.
  However macro expansion does occur inside backquotes.

+ Macro expansion is also handled as the very first thing the
+ interpreter does when looking at a new line of commands and is only
+ done once. Therefore, code like the following will execute correctly:
+
+      A = "c=1"
+      @A
+
+ but this line will not, since the macro is defined on the same line
+ and can't be expanded in time
+
+      A = "c=1"; @A   # will not expand to c=1
+
  For execution of complete commands the `evaluate` command may also be
handy.
 3 String variables, macros, and command line substitution
 ?mixing_macros_backquotes

-------------------end----------------------

Thanks for the quick help

Arun

Re: macro bug?

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday, March 31, 2011, Arun Persaud wrote:
> Hi
> 
> not sure if this is a bug or not...
> 
> the following works:
> 
> gnuplot> set macros
> gnuplot> A="a=1"
> gnuplot> a=1.0
> gnuplot> A=sprintf("a=%f",2)
> gnuplot> @A
> gnuplot> print a
> 2.0
> 
> but this doesn't:
> 
> gnuplot> set macros
> gnuplot> A="a=1.111";a=1;A=sprintf("a=%f",2);  @A;print a
>          warning: A is not a string variable


The macro mechanism was a first attempt at string handling.
It didn't really work out all that well.
Proper string handling replaced it for most purposes, and perhaps
the macro stuff should have been removed, but we're such sticklers
for backwards compatibility that it's still there.

Anyhow...
The problem you're seeing is inherent in the way that the macros work.
They are applied line-by-line to the input stream, as the very first
thing before the line is actually interpreted or executed.
But that means if you define a new macro on a particular line,
that line has already been through the macro substitution process
and substitutions involving the new macro cannot take effect until
the next line.

	Ethan 



> 1
> 
> 
> I also ran into something similar, here is a short version of it:
> 
> set macros
> A="2.0"
> f(t) = (\
>          A= sprintf("a=2.0"),\
>          @A,\
>          "some text")
> 
> print f(1)
> 
> that didn't set a to 2.0...
> 
> An here a longer: What I wanted to do is having a function that saves
> results from a fit to some variables, so that I can reuse them later
> after doing more fits... I thought I could use:
> 
> CP_FIT(A,A_err,mu,mu_err,sig,sig_err,offset,offset_err,file,type) = ( \
>        MA    = sprintf("%s_%s_A       = %f",file,type,A),\
>        MAe   = sprintf("%s_%s_A_err   = %f",file,type,A_err),\
>        Mmu   = sprintf("%s_%s_mu      = %f",file,type,mu),\
>        Mmue  = sprintf("%s_%s_mu_err  = %f",file,type,mu_err),\
>        Msig  = sprintf("%s_%s_sig     = %f",file,type,sig),\
>        Msige = sprintf("%s_%s_sig_err = %f",file,type,sig_err),\
>        Moff  = sprintf("%s_%s_off     = %f",file,type,offset),\
>        Moffe = sprintf("%s_%s_off_err = %f",file,type,offset_err),\
>        @MA, @Mmu, @Msig, @MAe, @Mmue, @Msige,@Moff,@Moffe,\
>        sprintf("copying variables for %s %s",file,type))
> 
> but the macros never got called ?! It works though, if I take the line
> including all the @M... out and call it by hand after I call CP_FIT.
> 
> Tested this with 4.4, 4.5 and the latest CVS (Changelog version 1.3682).
> Here is the version output from the CVS build:
> gnuplot> show version long
> 
> 	G N U P L O T
> 	Version 4.5 patchlevel 0
> 	last modified March 2011
> 	System: Linux 2.6.38-18-desktop
> 
> 	Copyright (C) 1986-1993, 1998, 2004, 2007-2010
> 	Thomas Williams, Colin Kelley and many others
> 
> 	gnuplot home:     http://www.gnuplot.info
> 	mailing list:     gnu...@li...
> 	faq, bugs, etc:   type "help seeking-assistance"
> 	immediate help:   type "help"
> 	plot window:      hit 'h'
> Compile options:
> -READLINE  +LIBREADLINE  +HISTORY
> -BACKWARDS_COMPATIBILITY  +BINARY_DATA
> +GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
> -NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
> +HIDDEN3D_QUADTREE
> +DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE
> +USER_LINETYPES
> 
> GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/4.5"
> GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/4.5/PostScript"
> HELPFILE           = "/usr/local/share/gnuplot/4.5/gnuplot.gih"
> 
> cheers
> 
> ARUN
> 
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself; 
> WebMatrix provides all the features you need to develop and 
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: macro bug?

[Arun P. <ape...@lb...>]

Hi

On 03/31/2011 07:09 PM, Daniel J Sebald wrote:
> On 03/31/2011 08:32 PM, Arun Persaud wrote:
>> [...]
> That does seem inconsistent.
> 
> Did you try the "table" feature for saving results to a file?  Look at
> the third example of "random.dem" demo to see how a data file of random
> numbers is created then used in a plot.

no. I haven't. Guess that could be a nice workaround for saving my fit
data for later plotting. However I would lose the parameters themselves
and wouldn't be able to include them for e.g. labels. For the moment, I
just "unrolled" the function containing the macros and that worked... of
course now I have to do edits in many places and not just one ;)

Arun

Re: macro bug?

[Daniel J S. <dan...@ie...>]

On 03/31/2011 08:32 PM, Arun Persaud wrote:
> Hi
>
> not sure if this is a bug or not...
>
> the following works:
>
> gnuplot>  set macros
> gnuplot>  A="a=1"
> gnuplot>  a=1.0
> gnuplot>  A=sprintf("a=%f",2)
> gnuplot>  @A
> gnuplot>  print a
> 2.0
>
> but this doesn't:
>
> gnuplot>  set macros
> gnuplot>  A="a=1.111";a=1;A=sprintf("a=%f",2);  @A;print a
>           warning: A is not a string variable

That does seem inconsistent.

Did you try the "table" feature for saving results to a file?  Look at 
the third example of "random.dem" demo to see how a data file of random 
numbers is created then used in a plot.

Dan

macro bug?

[Arun P. <ape...@lb...>]

Hi

not sure if this is a bug or not...

the following works:

gnuplot> set macros
gnuplot> A="a=1"
gnuplot> a=1.0
gnuplot> A=sprintf("a=%f",2)
gnuplot> @A
gnuplot> print a
2.0

but this doesn't:

gnuplot> set macros
gnuplot> A="a=1.111";a=1;A=sprintf("a=%f",2);  @A;print a
         warning: A is not a string variable
1


I also ran into something similar, here is a short version of it:

set macros
A="2.0"
f(t) = (\
         A= sprintf("a=2.0"),\
         @A,\
         "some text")

print f(1)

that didn't set a to 2.0...

An here a longer: What I wanted to do is having a function that saves
results from a fit to some variables, so that I can reuse them later
after doing more fits... I thought I could use:

CP_FIT(A,A_err,mu,mu_err,sig,sig_err,offset,offset_err,file,type) = ( \
       MA    = sprintf("%s_%s_A       = %f",file,type,A),\
       MAe   = sprintf("%s_%s_A_err   = %f",file,type,A_err),\
       Mmu   = sprintf("%s_%s_mu      = %f",file,type,mu),\
       Mmue  = sprintf("%s_%s_mu_err  = %f",file,type,mu_err),\
       Msig  = sprintf("%s_%s_sig     = %f",file,type,sig),\
       Msige = sprintf("%s_%s_sig_err = %f",file,type,sig_err),\
       Moff  = sprintf("%s_%s_off     = %f",file,type,offset),\
       Moffe = sprintf("%s_%s_off_err = %f",file,type,offset_err),\
       @MA, @Mmu, @Msig, @MAe, @Mmue, @Msige,@Moff,@Moffe,\
       sprintf("copying variables for %s %s",file,type))

but the macros never got called ?! It works though, if I take the line
including all the @M... out and call it by hand after I call CP_FIT.

Tested this with 4.4, 4.5 and the latest CVS (Changelog version 1.3682).
Here is the version output from the CVS build:
gnuplot> show version long

	G N U P L O T
	Version 4.5 patchlevel 0
	last modified March 2011
	System: Linux 2.6.38-18-desktop

	Copyright (C) 1986-1993, 1998, 2004, 2007-2010
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info
	mailing list:     gnu...@li...
	faq, bugs, etc:   type "help seeking-assistance"
	immediate help:   type "help"
	plot window:      hit 'h'
Compile options:
-READLINE  +LIBREADLINE  +HISTORY
-BACKWARDS_COMPATIBILITY  +BINARY_DATA
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +X11_EXTERNAL +USE_MOUSE
+HIDDEN3D_QUADTREE
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE
+USER_LINETYPES

GNUPLOT_DRIVER_DIR = "/usr/local/libexec/gnuplot/4.5"
GNUPLOT_PS_DIR     = "/usr/local/share/gnuplot/4.5/PostScript"
HELPFILE           = "/usr/local/share/gnuplot/4.5/gnuplot.gih"

cheers

ARUN

Re: wxt terminal in windows hangs

[Bastian M. <bma...@we...>]

Am 18.01.2011 15:29, schrieb Allin Cottrell:
> On Mon, 17 Jan 2011, sfeam (Ethan Merritt) wrote:
>
>> On Monday, January 17, 2011, Allin Cottrell wrote:
>>> On Mon, 17 Jan 2011, Allin Cottrell wrote:
>>>
>>>> On Tue, 18 Jan 2011, Mojca Miklavec wrote:
>>>>>
>>>>> My bet is that fc-cache runs in the background to regenerate font
>>>>> index "every now and then", so that one can use any given font on the
>>>>> system.
>>>
>>> (and this can take a looong time).
>>>
>>> I notice that in gnuplot's cp_cairo.c there's a comment (around
>>> line 690) about "working around a bug in the cairo/win32 backend
>>> for font rendering": the work-around involves gp_cairo on Windows
>>> using the freetype + fontconfig backend by preference to the win32
>>> backend.  Following Mojca's lead, this could explain the initial
>>> long wait for gnuplot output.
>>>
>>> I'm wondering, is the cairo bug in question still there?
>>> Unfortunately the comment is not specific (no bugzille ID). But if
>>> the issue is fixed in current cairo it could be worth making a
>>> change. Cairo's win32 backend doesn't have the problem of a long
>>> wait on first use.
>>
>> Here's a link to the original thread reporting the problem
>> in cairo's win32 backend:
>>
>> http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thread/5742a3d915085f7b/d075063d7da423e9?hl=en&ie=UTF-8&oe=utf-8&q=missing+pixels+for+Windows+PNG+driver&pli=1
>
> Thanks! I had a vague memory of that discussion but had forgotten
> the details. There have been a fair number of commits in the
> cairo-font-win32 area since then (14 months ago) so this is
> probably worth revisiting. I'll try some testing with cairo 1.10.2
> on Windows.
>
> Allin Cottrell

I have tried to reproduce the original bug report of the font problem
in cairopng with pango 1.28.3 and cairo 1.10.2 on Windows. The result
using current CVS (freetype + fontconfig) looks like this:
http://www.physi.uni-heidelberg.de/~bmaerk/tmp/gretl_bug.png
And here's the result using the win32 backend:
http://www.physi.uni-heidelberg.de/~bmaerk/tmp/gretl_bug-win32.png
Both versions look fine to me.

Should we apply the revised test you proposed?
 > #if CAIRO_VERSION_MAJOR < 2 && CAIRO_VERSION_MINOR < 10
Or should we test for the pango version here?

There's another reason why I would prefer that the cairo/pango
terminals use the win32 backend: In my experience, these
terminals (read: cairo/pango/fontconfig) fail to find a sensible default 
font ("Sans") on 4 out of 5 Windows machines. For me,
it fails on three different XP machines and on a Win 7 (x64)
machine. It only works on a Vista machine. This is the
result of 'enhancedtext.dem' using the pngcairo terminal with
no font specified:
http://www.physi.uni-heidelberg.de/~bmaerk/tmp/fontconfig-bug.png

   Bastian

Re: gnuplot.exe hangs instead of exiting on Windows 7

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

Hello


I have carried out gdb trace.

#******************************
$ gdb src/gnuplot
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from e:\usr\Tatsu\mingwhome\gnuplotcvs\gnuplot/src/gnuplot.exe...done.
(gdb) break WinExit
Breakpoint 1 at 0x532aa9: file win/winmain.c, line 157.
(gdb) run
Starting program: e:\usr\Tatsu\mingwhome\gnuplotcvs\gnuplot/src/gnuplot.exe
[New Thread 1284.0x1228]

        G N U P L O T
        Version 4.5 patchlevel 0
        last modified March 2011
        System: MS-Windows 32 bit

        Copyright (C) 1986-1993, 1998, 2004, 2007-2010
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        mailing list:     gnu...@li...
        faq, bugs, etc:   type "help seeking-assistance"
        immediate help:   type "help"
        plot window:      hit 'h'

Terminal type set to 'wxt'
gnuplot> exit

Breakpoint 1, WinExit () at win/winmain.c:157
157             term_reset();
(gdb) step
term_reset () at term.c:859
859         paused_for_mouse = 0;
(gdb) step
862         if (!term_initialised)
(gdb) step
863             return;
(gdb) step
882     }
(gdb) step
WinExit () at win/winmain.c:162
162             if (graphwin.hWndGraph && IsWindow(graphwin.hWndGraph))
(gdb) step
168             HtmlHelp(NULL, NULL, HH_CLOSE_ALL, (DWORD_PTR)NULL);
(gdb) step
[New Thread 1284.0x113c]
(HtmlHelp seems to hang here)

******************************
However
At the initial prompt
I carried out plot and close graph windows 
gnuplot> plot sin(x)
[New Thread 2124.0x1038]
After that

gnuplot> exit

Breakpoint 1, WinExit () at win/winmain.c:157
157             term_reset();
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) step
term_reset () at term.c:859
859         paused_for_mouse = 0;
(gdb) step
862         if (!term_initialised)
(gdb) step
863             return;
(gdb) step
882     }
(gdb) step
WinExit () at win/winmain.c:162
162             if (graphwin.hWndGraph && IsWindow(graphwin.hWndGraph))
(gdb) step
168             HtmlHelp(NULL, NULL, HH_CLOSE_ALL, (DWORD_PTR)NULL);
(gdb) step
[New Thread 2124.0xe78]
[New Thread 2124.0x5d4]
[New Thread 2124.0xe6c]
[New Thread 2124.0xbec]
185     }

This time HtmlHelp seemed to work correctly.

Perhaps something is wrong with initialization gnuplot.exe + HtmlHelp on windows 7.
A dummy plot? routine may avoid this fault as a temporal treatment. (It is of course curious method. )


Regards

Tatsuro
--- Tatsuro MATSUOKA wrote:

> 
> Hello
> --- Bastian M将」rkisch wrote:
> 
> > Hhhm. It shouldn't be. MSDN says:
> > 
> > "While Microsoft develops future Help technologies, we encourage Help authors 
> > to continue using HTML Help 1.4. HTML Help 1.4 is included in Windows篠7."
> > 
> 
> I have downloaded windows sdk for windows 7.  I found the htmlhelp.h and Htmlhelp.Lib in
> C:\Program
> Files\Microsoft SDKs\Windows\v7.1\Include and C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib,
> respectively.
> 
> I have tried to use htmlhelp.h and Htmlhelp.Lib in C:\Program Files\Microsoft SDKs\Windows\v7.1
> but
> they cannot be used as they are for current gnuplot cvs code on mingw.
> 
> As a reference I show the diff of htmlhelp.h between in the html help workshop and sdk :
> 
> *******************************
> --- htmlhelp.orig.h	1999-07-14 05:02:22 +0900
> +++ htmlhelp.sdk.h	2010-04-19 20:44:16 +0900
> @@ -17,10 +17,12 @@
>  extern "C" {
>  #endif  // __cplusplus
>  
> +#if _MSC_VER < 1200
>  // Defines for Win64
>  #ifndef _WIN64
>  #define DWORD_PTR DWORD
>  #endif
> +#endif
>  
>  // Commands to pass to HtmlHelp()
>  
> @@ -53,8 +55,10 @@
>  #define HH_SET_EXCLUSIVE_FILTER 0x0019  // set exclusive filtering method for untyped topics to
> be
> excluded from display
>  #define HH_INITIALIZE            0x001C  // Initializes the help system.
>  #define HH_UNINITIALIZE          0x001D  // Uninitializes the help system.
> +#define HH_SET_QUERYSERVICE     0x001E  // Set the Host IQueryService interface
>  #define HH_PRETRANSLATEMESSAGE  0x00fd  // Pumps messages. (NULL, NULL, MSG*). 
>  #define HH_SET_GLOBAL_PROPERTY  0x00fc  // Set a global property. (NULL, NULL, HH_GPROP)
> +#define HH_SAFE_DISPLAY_TOPIC   0x0020  // private addition to the interface for
> InternetExplorer.
>  
>  #define HHWIN_PROP_TAB_AUTOHIDESHOW (1 << 0)    // Automatically hide/show tri-pane window
>  #define HHWIN_PROP_ONTOP            (1 << 1)    // Top-most window
> @@ -364,19 +368,19 @@
>  HWND
>  WINAPI
>  HtmlHelpA(
> -    HWND hwndCaller,
> -    LPCSTR pszFile,
> -    UINT uCommand,
> -    DWORD_PTR dwData
> +    __in_opt HWND hwndCaller,
> +    __in LPCSTR pszFile,
> +    __in UINT uCommand,
> +    __in DWORD_PTR dwData
>      );
>  
>  HWND
>  WINAPI
>  HtmlHelpW(
> -    HWND hwndCaller,
> -    LPCWSTR pszFile,
> -    UINT uCommand,
> -    DWORD_PTR dwData
> +    __in_opt HWND hwndCaller,
> +    __in LPCWSTR pszFile,
> +    __in UINT uCommand,
> +    __in DWORD_PTR dwData
>      );
>  #ifdef UNICODE
>  #define HtmlHelp  HtmlHelpW
> @@ -424,3 +428,4 @@
>  #endif // __cplusplus
>  
>  #endif // __HTMLHELP_H__
> +
> ****************************************
> 
> Regards
> 
> Tatsuro
> 

Re: gnuplot.exe hangs instead of exiting on Windows 7

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

Hello

Sorry I have overlooked the below

>And we are using version 1.4 and the new Vista help system is not supported 
on XP or lower.

Regards

Tatsuro
--- Tatsuro MATSUOKA  wrote:

> 
> Hello
> --- Bastian M将」rkisch wrote:
> 
> > Hhhm. It shouldn't be. MSDN says:
> > 
> > "While Microsoft develops future Help technologies, we encourage Help authors 
> > to continue using HTML Help 1.4. HTML Help 1.4 is included in Windows篠7."
> > 
> 
> I have downloaded windows sdk for windows 7.  I found the htmlhelp.h and Htmlhelp.Lib in
> C:\Program
> Files\Microsoft SDKs\Windows\v7.1\Include and C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib,
> respectively.
> 
> I have tried to use htmlhelp.h and Htmlhelp.Lib in C:\Program Files\Microsoft SDKs\Windows\v7.1
> but
> they cannot be used as they are for current gnuplot cvs code on mingw.
> 
> As a reference I show the diff of htmlhelp.h between in the html help workshop and sdk :
> 
> *******************************
> --- htmlhelp.orig.h	1999-07-14 05:02:22 +0900
> +++ htmlhelp.sdk.h	2010-04-19 20:44:16 +0900
> @@ -17,10 +17,12 @@
>  extern "C" {
>  #endif  // __cplusplus
>  
> +#if _MSC_VER < 1200
>  // Defines for Win64
>  #ifndef _WIN64
>  #define DWORD_PTR DWORD
>  #endif
> +#endif
>  
>  // Commands to pass to HtmlHelp()
>  
> @@ -53,8 +55,10 @@
>  #define HH_SET_EXCLUSIVE_FILTER 0x0019  // set exclusive filtering method for untyped topics to
> be
> excluded from display
>  #define HH_INITIALIZE            0x001C  // Initializes the help system.
>  #define HH_UNINITIALIZE          0x001D  // Uninitializes the help system.
> +#define HH_SET_QUERYSERVICE     0x001E  // Set the Host IQueryService interface
>  #define HH_PRETRANSLATEMESSAGE  0x00fd  // Pumps messages. (NULL, NULL, MSG*). 
>  #define HH_SET_GLOBAL_PROPERTY  0x00fc  // Set a global property. (NULL, NULL, HH_GPROP)
> +#define HH_SAFE_DISPLAY_TOPIC   0x0020  // private addition to the interface for
> InternetExplorer.
>  
>  #define HHWIN_PROP_TAB_AUTOHIDESHOW (1 << 0)    // Automatically hide/show tri-pane window
>  #define HHWIN_PROP_ONTOP            (1 << 1)    // Top-most window
> @@ -364,19 +368,19 @@
>  HWND
>  WINAPI
>  HtmlHelpA(
> -    HWND hwndCaller,
> -    LPCSTR pszFile,
> -    UINT uCommand,
> -    DWORD_PTR dwData
> +    __in_opt HWND hwndCaller,
> +    __in LPCSTR pszFile,
> +    __in UINT uCommand,
> +    __in DWORD_PTR dwData
>      );
>  
>  HWND
>  WINAPI
>  HtmlHelpW(
> -    HWND hwndCaller,
> -    LPCWSTR pszFile,
> -    UINT uCommand,
> -    DWORD_PTR dwData
> +    __in_opt HWND hwndCaller,
> +    __in LPCWSTR pszFile,
> +    __in UINT uCommand,
> +    __in DWORD_PTR dwData
>      );
>  #ifdef UNICODE
>  #define HtmlHelp  HtmlHelpW
> @@ -424,3 +428,4 @@
>  #endif // __cplusplus
>  
>  #endif // __HTMLHELP_H__
> +
> ****************************************
> 
> Regards
> 
> Tatsuro
>