forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

window_update@
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Thu Oct 22, 2015 10:59 pm    Post subject: window_update@ Reply with quote

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
View user's profile Send private message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Fri Oct 23, 2015 12:20 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sat Oct 24, 2015 3:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Oct 27, 2015 5:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Wed Oct 28, 2015 3:03 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Oct 28, 2015 9:00 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Fri Oct 30, 2015 11:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Oct 31, 2015 9:27 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Nov 10, 2015 9:50 am    Post subject: Reply with quote

In my earlier comment:

Quote:
uriously, 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


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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Nov 10, 2015 10:12 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
simon



Joined: 05 Jul 2006
Posts: 268

PostPosted: Fri Feb 10, 2017 8:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Feb 18, 2017 3:18 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sun Feb 19, 2017 9:52 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Sun Feb 19, 2017 11:49 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sun Feb 19, 2017 6:36 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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