Double call to callback functions

The following trivial program prompts for a number that can either be typed in or specified using the flywheels. If the user types in the number, function f is called once, but if one of the up or down arrows is clicked then function f is called twice. The double call to f may be causing some problems in a larger program. Is this double call supposed to occur?

MODULE m
!
CONTAINS
!
FUNCTION f()
!
INTEGER :: f
!
PRINT *, 'Test'
f=1
!
END FUNCTION f
!
END MODULE m
!
WINAPP
PROGRAM p
!
  USE clrwin, ONLY: winio@
  USE m
!
  INTEGER :: i,iw
!
  i=1
  iw=winio@('%dd%^rd',1,i,f)
!
END PROGRAM p

When I run it, the function is only called once (Windows 7 32bit, FTN95 6.10). I have tried it as coded by you in F90 style, and also modified to suit my Fortran-77 habit.

I suspect you have mouse sensitivity 'turned up' or some other unconventional mouse behaviour. Some other windows responses to a mouse click also detect a 'bounce' sometimes - e.g. some graphics inputs. To prove this to yourself, can you try it on a different machine?

I hate finding these sort of effects!

Eddie

Thanks Eddie. The integer is only increasing or decreasing by 1 after I click on the flywheels, which suggests I am only registering one click, and yet still getting two lines of output. But I'm intrigued that it works for you. Perhaps it is something specific to my version of Windows (XP SP3)?

This problem comes up from time to time and I think that I have tried before to fix it without success.

I get two calls to the callback both with reason 'DATA_ALTERATION'. Also occasionally I get an increase of 2 from a single click.

I will aim to have another go at fixing this.

Simon,

It incremented/decremented by 1, and only one message came up.

I tried your code on an XP machine, and it not only does a double callback, I got instances of 3 !

Perhaps it is time to move on from XP ! (I only just did).

Eddie

Hi Eddie,

Thanks for the information. It sounds like the problem is Windows version specific. I am expecting to convert to a newer version of Windows soon. However, this program is distributed all over Africa and South America, where some very old versions of Windows are still being used. So I'm hoping your diagnostic, and my simple program can point Paul to the problem. No pressure meant Paul! I could consider a list box format if this problem proves intractable.

Simon

I have had another go at this. The previous fix was OK with a grave on %rd but not without it. I am more confident about the new fix for %dd%rd.

In the mean time the following usage might help with the double call because the resulting values do not change between the first and second of the two calls.

MODULE m 
CONTAINS 
FUNCTION f()  
INTEGER :: f,addr,v,clearwin_info@ 
character*80 str,clearwin_string@
str = clearwin_string@('callback_reason')
addr = clearwin_info@('latest_variable')
v = core4(addr)
PRINT *, str, v
f=1 
END FUNCTION f 
! 
END MODULE m 
! 
WINAPP 
PROGRAM p 
  USE m 
  INTEGER :: i,iw,winio@ 
  i=1 
  iw=winio@('%dd%^rd',1,i,f) 
END PROGRAM p

Here's a proposed quick fix to prevent the calculations in the callback function being performed twice:

MODULE m
CONTAINS
 FUNCTION f()
  INTEGER :: f
  INTEGER :: k=0 ! - counter -
  f=1
  k=k+1
  IF (MOD(k,2)==0) RETURN
  PRINT *, 'TEST'
 END FUNCTION f
END MODULE m
!
WINAPP
PROGRAM p
  USE clrwin, ONLY: winio@
  USE m
  INTEGER :: i,iw
  i=1
  iw=winio@('%dd%^rd',1,i,f)
END PROGRAM p

I am not sure that you can rely on exactly two calls per click so I would suggest connecting the result of 'latest variable' with the value of i.

Thanks Paul. I am being a bit slow, and not seeing what I could do by comparing the 'latest variable' with i. In your program posted August 01, i and v take the same value at the first and the second call to the function. However, I think I can get the general idea: if i does not change between calls then we know that there is an unwanted second (or subsequent) call to the function. So would something like the following work?

MODULE m
 INTEGER :: i
 INTEGER :: j
CONTAINS
 FUNCTION f() 
  INTEGER :: f
  f=1
  IF (i==j) RETURN
  j=i
  PRINT *, i
 END FUNCTION f
END MODULE m
!
PROGRAM p
  USE m
  INTEGER :: iw,winio@
  i=1
  j=-1
  iw=winio@('%dd%^rd',1,i,f)
END PROGRAM p

Yes that is better and simpler to what I had in mind.

This problem has reared its ugly head again under Windows 10, although the original example program I provided seems to run ok. The solution I indicated no longer seems to work, so I was interested to explore Paul's suggestion to investigate clearwin_info@('latest_variable'). Now that clearwin_info returns an Integer(7) variable (or so the documentation claims) I modified the call to Core4 to Core8. However, it seems that the results only make sense if addr is declared as Integer(3) and I use core4.

addr = clearwin_info$('latest_variable')
print*, core4(addr)

Does that seem correct?

Unfortunately, the result is getting updated at each iteration; it is as if the button that activates the callback had been clicked many times. So I'm not really sure how to trap the problem anymore, and I have not been successful in reproducing the error in a small program, so I cannot post an example here. If I set the value of the callback function to 0 the function is always called only the once (as it should be), but, of course, closes the window. Setting the function to 1 or 2 generates the same problem. I was wondering whether there was some other way of forcing the callback function to return.

If the 'latest_variable' is an INTEGER4 then CORE4(addr) is correct. It returns the value of the INTEGER4 variable at the INTEGER(7) address addr.

Simon,

looking back at your original post reveals that you are using 'flywheels'. Isn't the point of a flywheel is that it has sufficient inertia that it keeps rotating? Hence, expected behaviour !

I sometimes find erratic spin wheel %dd behaviour, which appears to be worse in a faster computer, and it may well be the result of some timing issue. (I have one application where 0 goes to 1 reliably, but I can't 'catch' 2, but have to go back from 3.

I've been reading FTN95.CHM (I often do, it beats counting sheep), and in the description of %dd, its use with %rs is described, through the use of clearwin_string@('CALLBACK_REASON') and processing the reasons 'SPIN_UP' and 'SPIN_DOWN'. I thought that might be worth a try, but then I discovered the reason why an (ignored) non-zero step value has to be given - with a zero step, CW+ is smart and doesn't display the spin controls!

However, there's nothing to stop the programmer from using a proxy value in the display and processing the SPIN_UP and SPIN_DOWN on another variable, matching what is displayed by updating the control contents in the callback.

Or, you can junk %dd, and replace it with two small icons, each with their own callback. I've done this on occasion, and they are just as effective in some cases 'fore and aft' of the control or sometimes above and below it. The meaning is sometimes clearer than with %dd. You can also address the problem with a list box or drop down combo box, especially where the range of choice values is limited, and it is sometimes clearer to do so, e.g. instead of 'Symbol type 1, 2, 3 ...' to give the user 'circle', 'square', triangle' etc.

Eddie

Thanks Paul. So addr is Integer(3) if latest_variable is Integer(3), but clearwin_info is returning Integer(7), right?

Eddie, I think I'm going to go with your suggestion of a pull-down list. I would understand a flywheel to keep rotating if one clicked on it and kept the mouse button down, but to increment only by the step-value if the button is clicked in the normal way.

addr is INTEGER(7) which translates to INTEGER(3) in 32 bit mode and INTEGER(4) in 64 bit mode.

Simon,

The flywheel in my car keeps the engine rotating between mouse clicks, or as they are more commonly called, piston strokes. It's more important in a single cylinder engine, as without it you can't do a compression stroke.

I've now taken my own advice on drop down lists, and it is an improvement in usability when selecting an option (it was so easy in the past to include a number in an input file, and to translate that into a choice in the program); but when it is an actual number that is required, the spin controls are still useful, such as 'number of iterations'.

On the other hand, pre-definition of something, e.g. 'number of structural members' makes that old datafile type of input simpler, but when doing graphical input, it is easier just to keep track of additions and subtractions and make the number a derived quantity not a prescriptive one.

Eddie