forums.silverfrost.com

[Kenneth_Smith]

Excellent.

Looking at your videos, there is a significant delay in some cases between the button being pushed and the graph being refreshed. You might want to add something like this to the call backs that take a while to refresh the screen.

[Martin_K]

John,

I was on a business trip today and currently travelling back.
During my pause in travelling - just quick answer/question to you.

I do not understand what do you mean under: ...to be part lissing...
What do you mean?

I will incorporate Ken�s suggestion as soon
as I have little bit more time (maybe you also pointed to the fact that re-drawing of graphs with about 135000 points takes a while, whereas it can seem to the operator that program does nothing).

Martin

[Kenneth_Smith]

John�s comments remined me that with the new DLLs is should be possible to add scroll bars to the native %pl. Does anybody have a simple example they could share to demonstrate this in practice?

Ken

[PaulLaidler]

[Martin_K]

Ken,

Today, I implemented your suggestion regarding to significant delay (in some cases) between the pushing a button and subsequent re-drawing the graphics - many thanks, now it works!

However - I lost nearly 2 hours with this simple task! I was already totally frustrated, since it did not work with my code.
I did not know further what I should do, so as last desperate attempt, I changed the graphical representation of the grid points from symbol 12 to symbol 10.

After this change, it worked IMMEDIATELY problem free with symbol 10!

Please - could you try the procedure with symbol 12 (and then, for example. with symbol 10), whether it will work with the symbol 12
or not and confirm my knowledge or negate it? In any case, when I pick symbol 12, I always have some big issues!

Thanks in advance!

Martin

P.S. I have the latest DLLs, MOD, INS and FTN95.EXE (v8.63) of June 22, 2020.

[Kenneth_Smith]

Martin,

Here is a modified version of the previous code which includes the change so that the simple splash screen appears:

https://www.dropbox.com/s/g8cg06abe8ypcj9/martin3.f95?dl=0

I have marked the changes in the code. In most cases 3 lines are added to each call back function.

And here is how it responds:-

https://youtu.be/PDrYfr_gUic

No problems with symbol = 12.

Ken

[Kenneth_Smith]

Martin,

here is a link to a slightly better implementation, which avoids the need for the global control variable. The control variable is now stored internal to the function temp_window() which creates, and removes the splash window.

The first call to the function temp_window() creates the splash window, the second removes it and so on.

https://www.dropbox.com/s/dzy1fboj21czitl/martin4.f95?dl=0

Again no problems with symbol = 12.

[Martin_K]

Ken,

thanks for your tips!

I found a hidden and sneaky bug in my code! It caused my big troubles with graphics in certain circumstances.

Namely, in one instance (under one IF construct), I used as a dummy argument the name, which I already used
elsewhere in the code as the name for a data object in a named COMMON statement.

This bug caused my troubles and lost of big amount of time.

Now, it is removed! Take a look at my video below, please, I will have a question.

I implemented (in a modified way) your suggestion regarding the display of info messages when the program does long calculations - thanks again for your countless inspirations!

[/url]
https://www.youtube.com/watch?v=btnBVB-CqNM&feature=youtu.be
[url]

As you can notice, at the time of about 25s from the start, I click on the menu (in EN: MAP/DISPLAY VECTOR MAP OF THE SR (Slovak Republic)



Here is a significant delay between the moment when the menu is selected and till the selected action is completed (drawing graphics for grid PLUS border line).
Similar delay can be observed at about 1m 55s from start, when I select the menu MAPA/ZOBRAZIŤ MRIE�KU (MAP/ONLY GRID DISPLAY).

In these both cases I would like to add an info message that something is happens (processing ...), but I am not sure, where in program is the right place for it. I achieved a result
(not good), when I placed such message in the corresponding plot call-back. It worked, but the information window never dismissed, although I used the same coding like for the buttons in the graphics.

When I placed the coding in the corresponding call-back for the menu item,
it also does not work as expected.

So, where should I place the code for info message?

Thanks in advance for your tip!

Martin

P.S. I will have a look at your last post (of Mon Jun 29, 2020 11:13 am) on Thursday,, since tomorrow I am very busy with another tasks.

[Martin_K]

Ken,

I identified the right place, where to put the splash window
when initially (for the first time) the graphics is drawn
(for both menu: MAP/DISPLAY VECTOR MAP SR and MAP/DISPLAY GRID ONLY).

Now, I see the splash window in the right place and it automatically dismisses when the selected task (via menu) is finished.

Do not waste your time with this!
(I will still have another topic for discussion ).

Martin

P.S.

Added a short video how it looks now:
[url]
https://www.youtube.com/watch?v=ZXD9r8hHphs
[/url]

BTW - why compiler did not make a notice that I used not allowed
use of the same name for a variable and the same name for a data object in a named COMMON statement? This was extremely time-consuming issue
for me.

As I detected the problem yesterday, I have no more problems with graphic symbols of points!

[Kenneth_Smith]

Good.

COMMON blocks can always cause problems, I prefer to put global variables in a MODULE.

At t = 32 s in the video I see the windows processing icon appear and you may get the program �not responding�. This can be avoided by a call to TEMPORARY_YIELD@() within CPU consuming loops.

Ken

[Martin_K]

I will add the function TEMPORARY_YIELD@() to the corresponding
part of my code.

I also use the MODULE possibility in the code (it is - by far - the most important part of my code), but I also have quite big amount of
COMMON statement (first of all an mainly in my main program and in a subroutine) and to re-code them would also be quite time-consuming task.
Anyway, I will minimize their use.

Martin

[LitusSaxonicum]

Ken,

I've always used COMMON blocks, without the slightest problem - at least once I mastered what they did. Putting global variables in a module is a great idea, but it does rather destroy the fundamental tenet in earlier versions of Fortran that the scope of a variable name was limited to a single subprogram, and that in fact there are no global variables! While I have no doubt that this is in many scenarios a great idea, it can be the very devil when you deal with old codes that relied on that scoping rule and implicit typing and mixing the two is where you can generate all sorts of problems.

And don't knock the old code base - for example, it was used to analyse things much better than we have today, like aeroplanes that got you from Heathrow to New York in a little over 3 hours.

Eddie

[Kenneth_Smith]

Eddie,

Knuckles have been wrapped with my steel ruler. Never did get a flight on Concorde.

Ken

[LitusSaxonicum]

Ken,

What a pity. Only �3000 each way in the 1990s, and being December there was a double air miles offer. As Concorde was always double First Class airmiles already, a trip for a meeting with New York lawyers provided the air miles or a family holiday. Frequent flyers left behind the leather 'gifts' and silver pens, and I collected enough for my Christmas presents that year.

On a subsonic flight the windows get cold, but on Concorde they got hot, and the aisle seat (2 each side like a 707) was the best. I've always asked for an aisle seat ever since ...

Incidentally, we won the case before an Arbitration Tribunal, but not before I'd also been to meetings in Australia and a day-and-a-bit site visit in Indonesia.

The business of mixing modules and COMMON is likely to create mayhem in a way that one or the other exclusively will not, after that it's a matter of taste.

Eddie

[JohnCampbell]

Eddie,

I have been gradually transitioning COMMON to MODULE.

The disadvantage of COMMON was they could be (re)defined each time they were used, but this was overcome by only using COMMON in an include file. Nevertheless, we are told COMMON is bad programming style, by those who make Fortran much more complex.

The advantage of MODULE is it allows derived types, which can assist with organising data property tables. ALLOCATE is also a big change (post F77) which is useful in modules.

A disadvantage of MODULES has been the vaguaries of using EQUIVALENCE.
It is interesting, that early on, I tried EQUIVALENCE in a MODULE and got an error message, which discouraged me from persisting with that approach.
However, equivalence can be used in modules, although its use is less of an issue; mostly can now be done differently.
I have seen COMMON used in a module, although I don't know why ! There is a SEQUENCE statement.

As for Common on the Concord, only �3000 each way might not be compatible.