forums.silverfrost.com

[FK_GER]

I've some problems to update an attached window. I've searched in the forum but I found no suitable help. Here, at first, the relevant part of my program:
(All data is declared correctly and available)

[Wilfried Linder]

Hi, I found the following information in the file cwplus.enh:

[John-Silver]

.... noting that for LOG scales it's now PLOT_REDRAW@ which should be used
see: http://forums.silverfrost.com/viewtopic.php?t=3487&postdays=0&postorder=asc&start=375
Paul's comments on 29th June & 30th June which implies that is in the v8.3beta279 dlls.

Also note in:
(Link corrected as 18_09_2018) !)
https://silverfrost.com/ftn95-help/clearwinp/simplepl/native.aspx

in the section starting: "The drawing of a graph can be delayed in one of three alternative ways: ..."
the procedure mentioned there.

and in 'Additional Notes' point 3 which talks about using %`PL to use a user-specified identifier for particular %pl's (so you can work with more than one if you like)you mention in your post you have x 2 ?)

And the EXAMPLE 2 there is worth studying as it brings several of these things into play.

____________________-

PAUL - just a quick question, where ìs the %`PL format documented ? (i.e. where do you put the identifier you want in the %`pl statement?)
(I assume it will eventually be put here: http://www.silverfrost.com/ftn95-help/clearwinp/formats/_pl.aspx )

PS1 - in that link just given I noticed the qualifier (?) listed, but with no description - what does it do ?

PS2 - in the first documentation linked to earlier above it's probably wise to include an asterisk against all occurences of 'SIMPLEPLOT_REDRAW' to say that for log plots 'PLOT_REDRAW' should be used.
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

[FK_GER]

The last days I've tested some possibilities to find a solution, but with no great success.

In doing so the subroutine was modified:
(k3 controls, if an update is to be done. At the first call k3=1, then 2,3,...)

[JohnCampbell]

I am by no means an expert in %pl, but I am unsure of your selection (and definition) of the 2 windows you are using and the separate definition of arrays for each window.

If you are updating windows, are the variables ist, xdata and ydata different and unique to the 2 windows ?

I would expect that to have 2 widows that you are updating, then the %pl argument addresses must be separate/unique for the 2 windows and these addresses must be maintained for each window.

Could window_update@ (xdata) or update_window@(hndl_eiz) work better.
I assume hndl_eiz are supplied integer*4 handles and not returned integer(7) handles ?

Is the following change necessary (or where are the graphics objects defined) ?

[John-Silver]

I'mnot sure how the %pl handles are created, which is why Iasked the question of Paul in my comment above of where the documentation of the grave qualifier for %pl is located.

Note also I've corrected one of the links in my previous comment.
Read the section starting 'The following functions can be called after a window has been formed in order to change the data. ' to see the use of the CHANGE_PLOT_DBL@ function and xample 2 for an application.

Then try inserting something like:
errstate = change_plot_dbl@(hndl_eiz,"x_data",all_graphs,xdata(1:ist,1))
errstate = change_plot_dbl@(hndl_eiz,"y_data",all_graphs,ydata(1:ist,1))

... and similarly for hndl_git ...
before the calls to simpleplot_redraw

On the error you're getting- I know it shouldn't make a difference if case insensitive, but in the CALL arguments list you have sdata and ydata but in the program you have xData and yData
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

[John-Silver]

Just a thought but I've just noticed that your handles variables are local to the subroutine.
Could this be affecting things as when you continually reenter the subroutine your trying to select a graphic object with that handle but what is ut's value on reentry - is it saved or does it go to zero or worse to gobbledygook ? (I'd love to know what the german word for gobbledygook is ! )

I'd have thought best to wsett up the windows first time round in a seperate routine. And pass all these variables globally vi a module , or at least via the subroutine parameter list?
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "

[FK_GER]

From your replies I recognize, that still some more explanations are necessary about the process of drawing.
If inside of the higher-level iteration process the program turns up to the drawing part, the calling subroutine FLAPLO sets the calculated data XZZ,YZZ to REAL*8 XPLOT,YPLOT for plotting as follows:

[Wilfried Linder]

I'm not familiar with %pl but from a theoretical point of view I would suggest the following:

[1] Define a set of variables for both plots, like XPLOT_1 and YPLOT_1 for the first graphics, XPLOT_2 and YPLOT_2 for the second. Initialise them at the beginning to zero.

[2] Make the data transfer via a common block like COMMON /PL_DATA/ XPLOT_1,YPLOT_1,XPLOT_2,YPLOT_2 (instead of transferring them via the variables list of the subroutines).

In this way, you don't need handles nor select_graphics-object@() or similar, and also you make sure that all relevant data are present when calling simpleplot_redraw@().

Good luck!

[Wilfried Linder]

Just to illustrate what I mean - a very small test programme, my first attempt with %pl

[FK_GER]

Hi,Wilfried,
thanks for the example. But there are a lot of obstacles in order to transfer these procedures to my program:
- The creation of the plot-data is an expensive iteration process with a lot of subroutines, which couldn't be installed simply into a function like shown in the example.
- The predominant parts of the program source code is written in F77. All significant arrays, under it the plot arrays xplot(..,..) yplot(..,..), are dynamically dimensioned in the main program and transferred over the calling lists into the subroutines.
- These two plot arrays are used during the flow of the program from three subroutines with in their dimensions very different plot data to show the calculated results. To put these plot arrays into fixed dimensioned common-blocks would be meant, that than an own fixed common-block has to be created for each plot, instead of one array for all plots as now.
- A problem at your proposal is, that your program opens one window with two plots, which are updated. But my program opens two windows each with one plot, which should be updated one after another. In doing so I suppose problems with the allocation.

Seeing that the program works without an "updating-windows" process, the operating expence to realise these update process like your proposal is too great. Then the results will shown in multiple windows still and not in one window only. The program user don't notice that, because the windows lie on top of each other exactly.
Maybe a way will be found to realise an update process, which matches to my actual procedure.

[Wilfried Linder]

OK.

Two windows with each one plot is no problem. For variable dimensions of the arrays you may use a module. Below is my next example, first the module, then the main program, the rest given as subroutines. Now written in the traditional f77 fixed format.

Perhaps this can help a little bit. If you like you may contact me via wilfried.linder@uni-duesseldorf.de - this might be easier for larger code examples.

[Wilfried Linder]

Some additional remarks:

Both windows in the example before are created once. The calculation subroutine abc only updates the graphics but creates no new windows.

I think that simpleplot_redraw@() needs the array data to be present either in common blocks or in modules, but they cannot be transferred via the parameter list. I may be wrong...

[Wilfried Linder]

Next addition:

In my examples, I use one-dimensional arrays (xplot_1,yplot_11,yplot_12,...). Now I tried to use two-dimensional arrays like you, and then got the error message "Invalid data value supplied to %PL" - exactly what you wrote on Monday 17.09., post from 3:54, marked in red.

So, it seems that %pl can only handle one-dimensional arrays.

Have a nice weekend
Wilfried

[John-Silver]

FK_GER.

I see from the sections of code you've posted so far that:-

FLAPLO contains a common block, which includes the indices of the sub-array used in the subroutine BI_EI_GI
... BUT ... The COMMON block doesn't appear in the subroutine !

In BI_EI_GI (and FLAPLO) the full arrays are passed in the parameter list, but only declared within the range (NWDIM,KU) . Is this a potential problem ?

What version number of ftn95 are you using exactly ?



P.S. almost forgot, the phrase you gave as an equivalent of gobbledygook - as it's relaed to language the english equivalent would be closer to 'Double Dutch' i.e. twice as difficult as Dutch is for english people, or 2x impossible to understand ! as in " I heard what he said but it was all double dutch to me" Gobbledygook can relate to many things, not just language as in: "C or C++ is complete gobbledygook to most Fortran users"
_________________
''Computers are incredibly rigid. They question nothing. Especialy input data.Human beings are incredibly trusting of computers and don't check input data. Together they are capable of cocking up even the simplest calculation ... "