forums.silverfrost.com

DanRRight · Posted: Sun Jul 01, 2018 10:12 am Post subject:

Paul,
As a hint, besides this my demo, other my codes fail to start with this new beta. One is complaining at stack overflow at second line (could be first actually as 64bit version was wrongly identified first executable line )

iSysYRES= GetSystemMetrics(SM_CYSCREEN),

and another immediately exits with not yet clear reason.

PaulLaidler · Posted: Sun Jul 01, 2018 2:00 pm Post subject:

Thanks Dan. I will await your code that demonstrates the fault.

DanRRight · Posted: Mon Sep 03, 2018 1:33 pm Post subject:

Paul,

I tried to simplify the demo by removing the necessity of reading big data files and processing it before plotting. Since plotted data is much smaller of course, I preliminary saved it on harddrive and when run the new demo I just loaded it right before plotting. The result was that this new demo also failed to plot the data dynamically on the simpleplot_update@ when I click on different radiobuttons but did not crash. This means that it's still better to use my older demo as it clearly has more useful "bugged" information.

PaulLaidler · Posted: Mon Sep 03, 2018 2:52 pm Post subject:

Dan

As far as I recall, I don't have anything useful from you to work on at the moment.

DanRRight · Posted: Tue Sep 04, 2018 7:30 am Post subject:

Paul, see my email on May 28.

PaulLaidler · Posted: Tue Sep 04, 2018 8:18 am Post subject:

Dan

I think that I must have looked at that sample before.

The first two run time failures are due to undefined values at lines 2770 and
2940 in the file called crashPL.for. These may not relate to the problem that you are experiencing with %PL but I need bug free code to work on.

DanRRight · Posted: Tue Sep 04, 2018 10:05 am Post subject:

Paul,

There probably still exist a lot of undefined variables, the original code was large. This part with undefined variables is doing reading of data and processing it for 1000 different purposes which are not needed for us, so i removed a lot of code but definitely not all. Removing it and scaling down took me more then a month. All still existing undefined variables have no relationship to the code which crashes, again, it just reads the data. Line 2770 for example is not used anywhere. The crashing part is very small, all is in the couple of small functions and is free of undefined things.

DanRRight · Posted: Tue Sep 04, 2018 1:13 pm Post subject:

Yes, John. I try to do elementary all we do many times per day: I displayed several curves on the same plotting area (like here below with just two curves shown),

and when I click appropriate radiobutton they have to appear or disappear. Fun is that I made two versions in the demo - one works OK and another uses a bit different initial data crashes when I click radiobuttons (crash happening on the line with "call simpleplot_update@" statement ). Also it does not allow to resize.

Older %PL by the way worked OK.

PaulLaidler · Posted: Tue Sep 04, 2018 1:52 pm Post subject:

Dan

If you can send me code that is free from Fortran bugs then I may be able to find time to work out why %pl is not doing what you expect.

LitusSaxonicum · Posted: Sun Sep 09, 2018 4:53 pm Post subject:

John,

Dan likes radio buttons of the round sort %rb instead of the square check boxes (%`rb) in defiance of convention, so therefore not ganged, and also (vide posts passim) likes them to be action buttons instead of a bunch of selections actioned together by a button of the %bt sort.

So yes, in Dan's universe, two radio buttons in the same group can be selected simultaneously.

Each to his own, even though perhaps I have met too many users whose Tourrette's Syndome is worsened by departure from Windows norms to plough such a convention-discarding furrow of my own!

Eddie

Kenneth_Smith · Posted: Sun Oct 14, 2018 12:00 pm Post subject:

One to be aware of if using multiple %pl regions and get_plot_data@.

In the example below there are two %pl regions, both with full mouse input.

Data in each plot is different and the plots have different sizes.

Moving the mouse across any of the regions and keeping an eye on the output window, it is apparent that the call back function correctly returns the pixel coordinates for each graph, however get_plot_data@ always returns the data corresponding to the last drawn plot.

Ken

PaulLaidler · Posted: Mon Oct 15, 2018 7:31 am Post subject:

Yes, the native %pl accesses the functionality of %gr and get_plot_data@ uses the associated "current drawing surface". %pl can take a grave accent together with the constant integer*4 value of an identifier provided by the programmer. This value (that you have chosen) can then be used in calls to select_graphics_object@ in order to set the "current drawing surface" before calling get_plot_data@.

Kenneth_Smith · Posted: Tue Oct 16, 2018 6:15 am Post subject:

Thanks Paul. Here's the code with Paul's suggestions. Runs OK in 32 bit, but there is a problem with 64 bit which I have yet to identify. 7th argument of the %pl should be 32 bit integer ??

PaulLaidler · Posted: Tue Oct 16, 2018 7:16 am Post subject:

plot1_handle and plot2_handle should be 32 bit integers even for 64 bits. So they should be declared as something like INTEGER(3) or INTEGER*4 or just INTEGER for the default INTEGER type.

Kenneth_Smith · Posted: Tue Oct 16, 2018 7:54 am Post subject:

Thanks Paul, Problem fixed Smile

I was sure I had read some where that these were to be kind=7. Corrected code below for those who wish to experiment.