Aleksandar Donev wrote:
>> http://www.star.le.ac.uk/~cgp/dislinGUI.html

> I want to comment briefly on this statement:
> 
> "The best way to do this in Fortran is to have the call-back routines in a 
> module, and set up module variables which are accessible to all the module 
> procedures and contain the information necessary to run the main computation. 
> In older versions of Fortran it was the practice to use common blocks for 
> this, but modules storage is much more, well, modular. "
> 
> I disagree that this is the "best way". It is a simple way that will work for 
> some (simple) uses. The problem is that modules are global, so there can be 
> only one per program. What if you have multiple list widgets that need to 
> have the same callback but work on different data (different windows for 
> example). It is ackward to code this using global variables.

Thanks, Aleksandar, for reading my notes and your comments.

Perhaps I should have said "better" rather than "best" as I only really 
saw two possibilities.  At present, as far as I can see, you either use 
modules or common blocks.  Since all of the descriptions I could find on 
the use of call-backs in Fortran used common blocks, including the 
examples in the DISLIN documentation, I thought it advocating modules.

Although modules are indeed global, one could provide and have access to 
more than one module containing suitable callback routines, and use 
different callback routines for different windows or widgets.   This 
gives a bit more flexibility, though I agree it is still a bit limited.

> In F2003 one can use polymorphism to pass "hidden" data to callbacks. But this 
> will not work with dislin since it does not pass context to callbacks.

The latter is not quite true: there is one integer identifier, which 
tells you which widget is invoking the callback.  It would be nicer to 
have more context, I agree, but that is sufficient for many situations, 
and I showed how to use it in one of my examples.

> In F2008 one will be able (finally!) to use internal procedures as callbacks. 
> Internal procedures can have access to data in their parent procedure so they 
> can share the context that way. 

That will be a useful improvement, but my notes were designed for those 
with current problems to solve, who might not be able to hold their 
breath until Fortran2008 compilers are widely available.


Regards

-- 
Clive Page