|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Thu Oct 22, 2015 10:59 pm Post subject: 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:
Code: | 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? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Oct 23, 2015 12:20 am Post subject: |
|
|
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". |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sat Oct 24, 2015 3:48 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Oct 27, 2015 5:51 pm Post subject: |
|
|
Curiously, WINDOW_UPDATE@ is discussed in on-line HELP here:-
http://silverfrost.com/ftn95-help/clearwinp/dialog/updatingwindows.aspx
but is not included in the more 'formal' syntactical LIBRARY REFERENCE here:-
http://silverfrost.com/ftn95-help/clearwinp/library/helpcontents1.aspx
Regarding the problem, the question as I see it is for Paul since obviously the parameter 'i' is being changed inside WINDOW_UPDATE@ since simon says the PRINT* before and after the CALL give a changed value.
I don't see how that can possibly be though. why would the WINDOW_UPDATE@ possibly want to change the value, it's function is simply to refresh all the controls which depend on that variable |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Wed Oct 28, 2015 3:03 am Post subject: |
|
|
John, you posted: Quote: | 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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Wed Oct 28, 2015 9:00 am Post subject: |
|
|
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.
Code: | 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
|
|
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Fri Oct 30, 2015 11:41 pm Post subject: |
|
|
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:
Code: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Oct 31, 2015 9:27 am Post subject: |
|
|
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. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Nov 10, 2015 9:50 am Post subject: |
|
|
In my earlier comment:
I guess what I was (silently) asking was . "Where (if it exists) is the syntactial documentation for WINDOW_UPDATE ?"
This post also grabbed my attention to the subject of 'TYPES' but I'll post a seperate topi so as not to hijack this post. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Nov 10, 2015 10:12 am Post subject: |
|
|
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. |
|
Back to top |
|
|
simon
Joined: 05 Jul 2006 Posts: 268
|
Posted: Fri Feb 10, 2017 8:01 pm Post subject: |
|
|
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.
Code: | 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
|
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Feb 18, 2017 3:18 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sun Feb 19, 2017 9:52 am Post subject: |
|
|
On further investigation, the following code illustrates that there may be something that needs fixing in Clearwin+.
Code: | 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. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sun Feb 19, 2017 11:49 am Post subject: |
|
|
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? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sun Feb 19, 2017 6:36 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|