window_update@

I suspect this may be one of those impossible questions to answer, but it is worth a try anyway! I have a program of about 70,000 lines in which there is the simplest of subroutines:

SUBROUTINE s(i)
USE clrwin, ONLY: window_update@
INTEGER, INTENT(IN) :: i
CALL window_update@ (i)
RETURN
END SUBROUTINE i

I am finding that occasionally the value of i after the call to window_update@ is different from that before, but that the subroutine returns even though i has changed and its INTENT is 'in' (I have tested by inserting PRINT statements immediately before and after).

Is there anything in window_update@ that could possibly result in a resetting of the argument?

In general, the value of 'i' will not be changed by the call to window_update@(). However, the window into which it is attached may change the value of 'i' asynchronously based on its usage. The INTENT(IN) has no real effect here since the routines that were targeted to work on 'i' in the ClearWin+ window have whatever access is needed to operate on 'i'.

window_update@() is only effective to update the window when the address of the variable being passed was also an argument in a ClearWin+ call; 'i' can certainly be changed by 'someone else'.

In the very worst case imaginable, this could be the result of a stack problem, avoided by having 'i' in COMMON, but stack problems usually bring the whole lot tumbling down.

You might just have better luck with the confusingly named UPDATE_WINDOW@, where the parameter is the handle of the window in question, if you want to experiment. The worst problem I've ever had with WINDOW_UPDATE@ is typing the name of the other subroutine by mistake!

Eddie

John, you posted:

since obviously the parameter 'i' is being changed inside WINDOW_UPDATE@

I don't think this is necessarily the case, as I have noted with a menu based %gr program and especially when using interrupt response, that variables can change values at unexpected times. It behaves as like a multi-threaded response and you have to be careful to check what could be changing the value. It could be more a timing problem. Is 'i' linked to some other winio@ structure?

I can confirm that window_update@(i) does not change the value of i. It passes the address of i and uses this address to update the screen for every control that displays the value of i. window_update@ processes the supplied address and does not touch its value.

The following sample illustrates the point and uses callbacks returning the value 2 in order to avoid the standard ClearWin+ mechanism for updating the screen.

module mydata
implicit none
integer i,j
contains

integer function cb1()
i = i + 1
j = j + 1
cb1 = 2
end function cb1

integer function cb2()
external window_update@
call window_update@(i)
cb2 = 2
end function cb2

integer function cb3()
external window_update@
call window_update@(j)
cb3 = 2
end function cb3

integer function cb4()
cb4 = 1
end function cb4

end module mydata

winapp
program myprog
use mydata
implicit none
integer winio@,wi
i = 1; j = 1
wi = winio@('%cni:%ta%`rd%2nl&',i)
wi = winio@('%cnj:%ta%`rd%2nl&',j)
wi = winio@('%cn%^tt[Increase]%2nl&', cb1)
wi = winio@('%cn%^tt[Update i]%2nl&', cb2)
wi = winio@('%cn%^tt[Update j]%2nl&', cb3)
wi = winio@('%cn%^tt[Update All]',cb4)
end myprog

Many thanks to all who responded. Perhaps I should provide a little bit more background on the problem, although as some of you have suggested, it is quite possible (actually, likely) the real problem is elsewhere.

Nearly all of the calls to window_update@ work as one would expect, but I have one integer parameter that is part of a fairly complex derived type that seems to get changed. There are other components of this derived type that are updated immediately before and immediately after, and those are all fine. More specifically, the variable that fails to gets changed and updated to the new value is defined something like the following:

MODULE m1
TYPE t1
   SEQUENCE
   INTEGER :: i1
   INTEGER :: i2
   INTEGER :: i3
END TYPE t1
TYPE t2
   SEQUENCE
   TYPE(t1) :: d1
   TYPE(t1) :: d2
END TYPE t2
END MODULE m1

MODULE m2
USE m1
TYPE t3
   SEQUENCE
! - various integer, character and derived type declarations (defined higher up in m2) -
   TYPE(t2) :: p1
   TYPE(t1) :: d3
END TYPE t3
TYPE(t3) :: dt
END MODULE m2

The first time I set all the values of dt, and window_update@ these everything is ok. Then if I reset the values of dt, and window_update@ again dt%d3%i1 is reset to the previous value for dt%p1%d1%i1. Of course, if I try to set up a simple example, the problem does not occur!

Anyway, if the above offers no further useful clues, I think I can implement a work around until I either find my own bug and/or can isolate any problem there might be in ClearWin+ in a manageable sample of code.

I guess that window_update@(dt%p1%d1%i1) will work for the i1 member and that window_update@(dt) will only be applied to the first scalar variable in the whole structure.

The nearest thing to a formal declaration can be found under 'Updating windows'. It is a subroutine with one argument that can have many different types.

I have eventually been able to isolate the problem I referred to about a ressignment of an argument by windows_update@. Below is a program that illustrates the problem. The program creates a window with an MDI frame containing an embedded child window (all of that seems to be necessary to reproduce the problem.) An integer, i, is set initially to 1, and is displayed. If the user then clicks on modify a callback function is activated that first changes i to 2, then to 0 (which is an invalid value for the display). As the program stands to be reset to between the fourth and fifth print statements, presumably to a value that is within the limits set by line 46. Note that if line 12 (that sets i to 2) or line 14 are commented out the reassignment no longer occurs, and i is left at 0.

Module m
  Public :: f
  Integer, Public :: i
!
Contains
!
 Function f()
  Use clrwin, Only: winio@, window_update@
  Integer :: f
!
  Print*, 'First ', i
  i = 2
  Print*, 'Second', i
  Call window_update@ (i)
  Print*, 'Third ', i
  i = 0
  Print*, 'Fourth', i
  Call window_update@ (i)
  Print*, 'Fifth ', i
  f = 2
!
  Return
 End Function f
End Module m
!
!
Winapp
Program p
  Use clrwin, Only: winio@
  Use m,      Only: i, f
!
  Integer :: ic_par, ic_con, ih_con, iw
!
  i = 1
!
! Open window
  iw = winio@('%ca@&', 'Test')
  iw = winio@('%mn[Modify]&', f)
! - create MDI frame -
  iw = winio@('%pv%fr&', 400, 300)
  iw = winio@('%lw', ic_par)
! - create child window -
  iw = winio@('%aw&', ic_par)
  iw = winio@('%ww[no_frame,no_caption]&')
! - display value -
  iw = winio@('%il&', 1, 10)
  iw = winio@('%dd%5rd&', 1, i)
  iw = winio@('%ff%`30.5cw[]&', 0, ih_con)
  iw = winio@('%lw', ic_con)
!
End Program p

This works OK for me but note that the final value i = 0 is out of range so you end up with the nearest value which is i = 1. Similarly if the final value is i = 42 then you get i = 10 on the screen.

On further investigation, the following code illustrates that there may be something that needs fixing in Clearwin+.

module m
integer n
contains
integer function f()
call window_update@(n)
print*,n
f = 2
end function f
end module m

program main
use m
integer iw,winio@
n = 42
iw = winio@('%il&',1,10)
iw = winio@('%rd&',n)
iw = winio@('%mn[Print]',f)
end

However, the main point is that if you use %il and then programmatically set the associated integer value to be out of this range then it is not unreasonable if ClearWin+ applies the range check. Calling window_update@ does not directly change n but it does trigger the %il range check.

An error message, perhaps? The existing behaviour looks rational to me. Can't you reset the limits now, and isn't that the logical thing to do before forcing the variable out of range by assigning an 'invalid' value to it?

At the moment, if you comment out the call to window_update@, then the initial internal value of n is different from the value on the screen. This needs fixing in some way.

In the next release the following code will behave as expected, feeding back the modified value of n as a result of applying %il.

module m
integer n
contains
integer function f()
print*,n
f = 2
end function f
end module m

program main
use m
integer iw,winio@
n = 42
iw = winio@('%il&',1,10)
iw = winio@('%rd&',n)
iw = winio@('%mn[Print]',f)
end