forums.silverfrost.com

[PaulLaidler]

Agustin

The main problem with your code is that you should not call ROTATE_FONT@ from the callback Legend. This is one of the routines "like SCALE_FONT@" referred to in the instructions.

The tick mark positions are not pleasing but maybe you can adjust the settings or use [dx=fval] and [dy=fval] to get a better result.

[aebolzan]

[aebolzan]

[PaulLaidler]

Agustin

Some of these plot symbols are already available with [native], see the extra styles added to the existing 0,1 and 2.

I have thought of a way to overcome the problem with calls to ROTATE_FONT@ and SCALE_FONT@ but I am not sure when I will be able to get this ready for you.

[aebolzan]

[DanRRight]

[aebolzan]

[DanRRight]

Of course if X_min and X_max are absent in %pl you have to cut the data yourself for all the plots but here I am talking about suggestion to add for future %pl. If there exist Y_min and Y_Max then there literally must be X_Min and X_Max. This is the key feature, all graphics programs in the world have it.

Another my suggestion is to make %pl not hang the code in any circumstances. Instead the warning window must pop out and tell something.

[aebolzan]

[PaulLaidler]

Dan

I will see if I can add x_min and x_max within the current design. This would be for use with the [x_array] option, otherwise the minimum and maximum x values can be provided as it is.

The suggestion about continuing after a ClearWin+ error is an interesting one but having thought about it, there are real obstacles to this.

1. Most ClearWin+ errors are not of a recoverable kind. The programmer's intention is paramount.

2. In most cases the ClearWin+ code is written so that there is no program path after a failure.

3. ClearWin+ would have to guess what was intended or use a default input value and this does not seem very helpful.

4. As things are that the moment, the exception handler would need to be developed otherwise there would be no trace-back and hence no information about where the failure occurred in user's code.

[PaulLaidler]

Agustin

As a minimum, it looks like we need a separate parameter for the symbol size.
I will see what can be done.

[LitusSaxonicum]

Paul,

As regards your 08:23 post, from the perspective of FTN95 an error message and program termination may be a tidy endpoint, but from the perspective of the user and the Fortran programmer it's a messy crash.

It looks like even Microsoft have given up on the idea that software can be crash-free, and so several of the latest generation MS Office products save work periodically and make recovery of those saved states possible. As programmers are probably many times more likely to be the source of these problems than FTN95, maybe it is encumbent on programmers to do the same, and that would catch even the odd case where FTN95/ClearWin+ was the problem!

Eddie

[PaulLaidler]

Eddie

I think that we may be referring to different things.

The ClearWin+ errors that I was thinking of relate to errors that the developer encounters when writing the code. They are like compile time errors in a way but currently are not detected until run time. They almost exclusively relate to winio@.

As such the developer should test every path through the code and make sure that the correct arguments etc. are passed. One hopes that this kind of error never gets to an end user.

As an experiment, the next release will include a feature where some winio@ error reports will be provided at compile time rather than run time. For the purpose of the experiment, the feature will be limited to /64 and /check. But just as at runtime, the first such error will be fatal. That is the nature of the beast. For me, given the speed of compilation, that is not a problem. I just deal with the errors one at a time and click on the compile or build button between changes.

[aebolzan]

well, it seems that the implementation of symbols is not something straightforward.....moreover, I would say that it is quite confusing. For instance,

CASE 1

CALL winop@("%pl[width=2]")
CALL winop@("%pl[colour=blue,style=6,pen_style=2]")

you get blue filled squares...but if you just change the width and set

CASE 2

CALL winop@("%pl[width=3]")
CALL winop@("%pl[colour=blue,style=6,pen_style=2]")

you get a different symbol, something that I couldn't define very well, so that, the problem is not only to define a separate parameter for symbol size, but to see how symbols are defined

with

CASE 3

CALL winop@("%pl[width=4]")
CALL winop@("%pl[colour=blue,style=0,pen_style=2]")

you get seemingly the same symbols as CASE 1, although it is probably due to the fact that the type of line (style = 0 is for line plots, isn't it?) results in something that is visually very close to the symbols in CASE 1

Seemingly, you need at least width = 3 in order to display a really distinguishable symbol.

Speaking about symbols, style=5 gives you open "45 degree-rotated" squares, style=4,
open down-triangles, style=3, open up-triangles, style=2, filled squares (but you need width=4 to distinguish them) and style=1, "original" open squares with a mark inside. I would say that the only "classical" symbols that are lacking are the open and filled circles.

Pen_style is irrelevant when you use styles 1, 3, 4, 5, 6, as it only controls line plots.

Agustin

[aebolzan]

Besides my previous comments about symbols, I would like to add some additional personal thoughts about the new implementation of %pl:

1) why not change the option "pen_style" to "line_style", as this would be more specific? (pen_style works only for lines)

2) why not define an option "plot_style" instead of "style" , i.e. plot_style 0 and 1 would be lines and 2 scatter (i.e. symbols, as what we get with style = 1). ?

3) why not define options "symbol_size" for scatter plots and "line_width" for line plots instead of a single "width" option that affects both types of plots?

4) why not define an option "[symbol=uptriangle,downtriangle,opensquare,etc.]", instead of the actual "[style =1,3,4,5,6]", as these numbers say nothing to the user, unless he/she remembers the meaning of these numbers....

I do not know if such implementations would result in a lot of additional work to the new implementation of %pl or would introduce some other problems......you know that better than me Paul...

Agustin