gnuplot-beta

Re: Visual basic Interface

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

On Thu, 22 Jul 2004 ren...@ya... wrote:

> I want to build an interface with Visual basic 6.0 for
> a project in my school.

I'm not sure you'll be up to this unless you have some
serious lower-level programming experience with Windows.

Get yourself the gnuplot sources, and look at the source to the
pgnuplot.exe program.  If you don't understand what you see there, odds
are you won't be able to pull this off.

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

Re: Visual basic Interface

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

On Thu, 22 Jul 2004, Justace Clutter wrote:

> I think that a starting point can also be the kile application. 

If he were on Linux, that would be a useful way to start off.  But not on
MS Windows, where gnuplot works rather differently from Unix/X11 builds.

MS Windows doesn't subscribe to the concept of GUI applications having a
connection to a command line (standard input/output channels) --- like
gnuplot running in an xterm (or piped to a controlling application), and
gnuplot_x11 does the graphical I/O.

That's where pgnuplot.exe comes in.  It's a console app, so it can
be run via pipes.  It then runs an instance of the normal windows
gnuplot and feeds all the characters arriving at its stdin to the
message queue of wgnuplot.

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

Re: Visual basic Interface

[Justace C. <pro...@co...>]

I think that a starting point can also be the kile application.  There
is a gnuplot interface there.  It is done in QT for linux but I am sure
that it can be somewhat instructive.  You could also just write a
frontent for it to create a gnuplot command list and then pipe that to
an instance of gnuplot.  That will save you from a lot of low level
stuff.

Justace

On Thu, 2004-07-22 at 18:11, Hans-Bernhard Broeker wrote:
> On Thu, 22 Jul 2004 ren...@ya... wrote:
> 
> > I want to build an interface with Visual basic 6.0 for
> > a project in my school.
> 
> I'm not sure you'll be up to this unless you have some
> serious lower-level programming experience with Windows.
> 
> Get yourself the gnuplot sources, and look at the source to the
> pgnuplot.exe program.  If you don't understand what you see there, odds
> are you won't be able to pull this off.

Re: Visual basic Interface

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

Justace Clutter wrote:

>I think that a starting point can also be the kile application.  There
>is a gnuplot interface there.  It is done in QT for linux but I am sure
>that it can be somewhat instructive.  You could also just write a
>frontent for it to create a gnuplot command list and then pipe that to
>an instance of gnuplot.  That will save you from a lot of low level
>stuff.
>  
>

Justace,

Please explain what kile and QT are.  This rentor98 may be a newbie... 
like myself.  I gather what you are saying is that this person may want 
to seek out similar applications to Excel but for which there is plenty 
of documentation available about building the software?

My advice is to heed Hans' warning.  My experience with low-level stuff 
on a Microsoft platform is frustration.  First, I got sucked in, 
thinking "oh all I need do is modify this or that and then ba-da-bing". 
 But then I got to the point of having to interface with drivers and 
DLLs.  Some frustrating system errors for legitimate reasons like parity 
failures, or what not.  So then I thought I could go to Microsoft's web 
site and get the tools to recompile a driver.  That lead to lots of 
searching and when I found something that looked applicable, I had a zip 
file full of so many files I didn't know where to start.  It's as though 
you can't dip your toes in the water, you have to become an all out 
Microsoft developer.

In my case I then sought out solutions in linux.  I learned a lot about 
launching subprocesses, building and installing drivers, low level I/O, etc.

Dan

Plot placement, revisited

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

If you recall, there was a discussion of precisely controlling the size 
of a plot.  It concerned how labels would take away space from the plot 
so that the eventual size of the borders was random, or at least not 
known to the user.  The solution was to set the margins to 0, for which 
the values specified in "size" matched the borders of the plot.  That 
worked fine.

But there is a similar situation with the key.  When the key is 
specified as "below", that uses up space, so again "set size X,Y" is no 
longer the precise size of the borders.  There is an option for 
specifying the location of the key, "set key x,y", which does not use up 
space.  That would work, but unfortunately there seems no way to 
independently control "maximize number of columns" vs. "maximize number 
of rows".  Instead, here is the control structure within the code:

    if (key->flag == KEY_AUTO_PLACEMENT) {
        if (key->vpos == TUNDER) {
            /* maximise no cols, limited by label-length */
        } else {
            /* maximise no rows, limited by ytop-ybot */
        }
    }

It would be nice to be able to control the "max no cols" vs. "max no 
row" independent of the autoplacement.  As it stands, there is no 
"above" autoplacement, only "below";  and there is the using up space 
issue I've mentioned.

Depending upon the interior lines of the plot, someone might even want 
to have a "maximize no cols" and place it somewhere within the borders. 
 So, I would argue for making these independent.  That is, perhaps a 
"maxcols"/"maxrows" key word.  Imagine there were independent keywords

right, left, center, bottom, top
maxcols, maxrows
inside, outside

The first set of keywords would control the 9 possible "default" locations.

1 2 3
4 5 6
7 8 9

1 - left top
2 - top center
3 - top right
4 - left center
5 - center
6 - right center
7 - bottom left
8 - center bottom
9 - right bottom

(#5 seems like a goofy choice, but so be it.)

Also, the same combinations make sense no matter if you say 
independently "outside" versuse "inside".  Same for "maxcols" vs. "maxrows".

Then, in one sense, the current keywords "outside" and "below" actually 
have multiple meaning.  "outside" really means "outside, right/center, 
maxrows"; "below" really means "outside, bottom/center, maxcols".

Dan

Re: Plot placement, revisited

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

On Friday 23 July 2004 12:09 pm, Daniel J Sebald wrote:
> 
> It would be nice to be able to control the "max no cols" vs. "max no 
> row" independent of the autoplacement.  As it stands, there is no 
> "above" autoplacement, only "below";  and there is the using up space 
> issue I've mentioned.

I quite agree with you that the current setup has lots of problems.
I thought a bit about trying to introduce explicit code to control the
number of rows and columns. Then I looked at the code and shuddered.

Then I thought some more and decided that a better goal was to
work toward generalizing the setup in a different way.  I started by
moving all the key-specific data into a single structure, with the idea
that one could then support multiple keys.  Rather than trying to 
control the column layout with a key, you would instead assign
half the plots, say, to one key box and the other half to a second
key box.   Each box could be separately positioned in x and y.
It would look to the user something like

	set key 1 title "First Half" at x1, y1
	set key 2 title "The Rest" at x2, y2
	plot 'data' u 1:2 key 1 title "whatever, \
                    '' u 1:3 key 2 title "whatever"

and so on.

I never got any further than that in coding, but anyway that's my
suggestion as to what we might aim for.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Plot placement, revisited

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

Ethan Merritt wrote:

>On Friday 23 July 2004 12:09 pm, Daniel J Sebald wrote:
>  
>
>>It would be nice to be able to control the "max no cols" vs. "max no 
>>row" independent of the autoplacement.  As it stands, there is no 
>>"above" autoplacement, only "below";  and there is the using up space 
>>issue I've mentioned.
>>    
>>
>
>I quite agree with you that the current setup has lots of problems.
>I thought a bit about trying to introduce explicit code to control the
>number of rows and columns. Then I looked at the code and shuddered.
>

Just a bit disorganized, I think.  Not too bad.

>Then I thought some more and decided that a better goal was to
>work toward generalizing the setup in a different way.  I started by
>moving all the key-specific data into a single structure, with the idea
>that one could then support multiple keys.
>

I thought of the multiple keys thing too.  Not how to do it, but the 
possibility of doing it.


>  Rather than trying to 
>control the column layout with a key, you would instead assign
>half the plots, say, to one key box and the other half to a second
>key box.   Each box could be separately positioned in x and y.
>It would look to the user something like
>
>	set key 1 title "First Half" at x1, y1
>	set key 2 title "The Rest" at x2, y2
>	plot 'data' u 1:2 key 1 title "whatever, \
>                    '' u 1:3 key 2 title "whatever"
>
>and so on.
>
>I never got any further than that in coding, but anyway that's my
>suggestion as to what we might aim for.
>

You are directing, then, which key the signal should go into.  I like 
that.  That sort of fits the general philosophy of gnuplot.

Walking across town, I've sort of concluded that keywords 
"horizontal/vertical" would be more appropriate than "maxcols/maxrows". 
 I'll attempt a simple patch to introduce these keywords.  Not a full 
implementation, but something that at least allows me to manually 
position a horizontal key so I can finish the plot I'm after.

Dan

Re: Plot placement, revisited

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

Ethan Merritt wrote:

>I quite agree with you that the current setup has lots of problems.
>I thought a bit about trying to introduce explicit code to control the
>number of rows and columns. Then I looked at the code and shuddered.
>

Now I see what you are saying.  There is code for the key all over 
"graphics.c".

And I think I see why the "set key below" always causes space removed 
irregardless of the "bmargin" setting.  It isn't conditioned the way 
"set key out" and "rmargin" is, ie for TOUT it's

    if (rmargin < 0) {
<snip>
      /* adjust for outside key */
      if (key->flag == KEY_AUTO_PLACEMENT && key->hpos == TOUT) {
          xright -= key_col_wth * key_cols;
          keybox.xl = xright + (int) (t->h_tic);
      }
<snip>
    } else

but for TUNDER, it's

    if (key->flag == KEY_AUTO_PLACEMENT) {
        if (key->vpos == TUNDER) {
<snip>
        ybot += key_entry_height * key_rows + (int) ((t->v_char) * 
(ktitl_lines + 1));
        ybot += (int)(key->height_fix * (t->v_char));
        } else {
<snip>
    }

Dan

Re: Plot placement, revisited (memory leak)

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

Daniel J Sebald wrote:

> Ethan Merritt wrote:
>
>> I quite agree with you that the current setup has lots of problems.
>> I thought a bit about trying to introduce explicit code to control the
>> number of rows and columns. Then I looked at the code and shuddered.
>>
>
> Now I see what you are saying.  There is code for the key all over 
> "graphics.c". 


And also graph3d.c has some of the similar code replicated... not good.

The "show key" may have a memory leak.  There is a magic number for 
memory allocation:

    char *str = gp_alloc(30, "show_key");

and, actually, the fact the string gets pumped to stderr means there 
really isn't any need for "str".  Anyway, the above allocation is done 
*every* time the routine is entered.  But the free is only done 
conditionally on KEY_AUTO_PLACEMENT.

I created a script file with "show key" repeated several times. 
 Watching system memory, when KEY_AUTO_PLACEMENT is active, loading that 
file does nothing to system memory.  But after "set key 30,30", calling 
said script file builds up system memory.

Dan

Re: Plot placement, revisited

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

And here is another inconsistency.  Try the following and watch were the 
key is in each case:

set key outside
plot sin(x)
set key under
replot
set key outside
replot

I've pretty much got a patch with additional enumerations (below) that 
is meant to mimic the current behavior of key placement.  So, maybe wait 
a couple days so I can test it.  The idea would be to move the fixes and 
new enumerations in right away, then modifications to the placement 
behavior can be done over time as a patch on sourceforge.

Dan



/* The stacking direction of the key box: (vertical, horizontal) */
typedef enum en_key_stack_direction {
    VERTICAL,
    HORIZONTAL
} t_key_stack_direction;

/* The region, with respect to the border, key is located: (inside, 
outside) */
typedef enum en_key_region {
    INTERIOR,
    EXTERIOR
} t_key_region;

/* The vertical positioning of the key box: (top, bottom, center) */
typedef enum en_key_vertical_position {
    VTOP,
    VBOTTOM,
    VCENTER
} t_key_vertical_position;

/* Horizontal positions of the key box: (left, right, center) */
typedef enum en_key_horizontal_position {
    HLEFT,
    HRIGHT,
    HCENTER
} t_key_horizontal_position;

Re: Plot placement, revisited

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

I've put a patch on SourceForge (997001 key cleanup and enhancement) 
that has the enumerations described previously, fixes the memory leak, 
makes "outside" and "under" more consistent.  Otherwise, it mimics the 
behavior of the current key placement rules.  Please consider moving it 
into CVS, in which case it can serve as a starting point for further key 
development.

Dan




Daniel J Sebald wrote:

> I've pretty much got a patch with additional enumerations (below) that 
> is meant to mimic the current behavior of key placement.  So, maybe 
> wait a couple days so I can test it.  The idea would be to move the 
> fixes and new enumerations in right away, then modifications to the 
> placement behavior can be done over time as a patch on sourceforge.
>
> Dan
>
>
>
> /* The stacking direction of the key box: (vertical, horizontal) */
> typedef enum en_key_stack_direction {
>    VERTICAL,
>    HORIZONTAL
> } t_key_stack_direction;
>
> /* The region, with respect to the border, key is located: (inside, 
> outside) */
> typedef enum en_key_region {
>    INTERIOR,
>    EXTERIOR
> } t_key_region;
>
> /* The vertical positioning of the key box: (top, bottom, center) */
> typedef enum en_key_vertical_position {
>    VTOP,
>    VBOTTOM,
>    VCENTER
> } t_key_vertical_position;
>
> /* Horizontal positions of the key box: (left, right, center) */
> typedef enum en_key_horizontal_position {
>    HLEFT,
>    HRIGHT,
>    HCENTER
> } t_key_horizontal_position;
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/