| View previous topic :: View next topic |
| Author |
Message |
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
 Posted: Wed Mar 16, 2011 10:00 am Post subject: Failed redraw using allocatable array in plot routine (Win7) |
 |
|
Maybe somebody can shed light on this, it's a simple test program that should display a rectangle+lines but fails to do so on Win7 when compiling with checkmate. debug-only as well as release works fine, when tracing a checkmate build a breakpoint at the allocate is reached but execution does not continue (there's not much information to derive from the disassembly using sdbg in this case).
Test code (compile with ftn95 /checkmate resize.f95 /link ):
| Code: | module module_resize
integer*4, parameter :: idimension_min = 2000
integer*4, parameter :: idimension_max = 10000
integer*4 :: idimension = 2000
integer*4, allocatable,dimension(:) :: ipoint_x, ipoint_y
! integer*4, dimension(idimension_max):: ipoint_x, ipoint_y ! fixed-size array, works fine
integer*4 :: ixwin = 300
integer*4 :: iywin = 300
integer*4 :: mydc = 8
integer*4, parameter :: x1 = 100
integer*4, parameter :: y1 = 100
end module module_resize
!=======================================================================================================
winapp
!=======================================================================================================
use module_resize
implicit none
integer :: i
external redraw
i = winio@('%ww[no_border]&')
i = winio@('%ca[Resizing Test]&')
i = winio@('%ob&')
i = winio@('%pv%^`gr[white,user_resize,rgb_colours]&', ixwin,iywin,mydc,redraw)
i = winio@('%cb')
end
!=======================================================================================================
integer function redraw()
!=======================================================================================================
use module_resize
implicit none
include <windows.ins>
character(len=20) :: cwstring
redraw=2
cwstring = clearwin_string@('call_back_reason')
if (cwstring == 'RESIZE') then
ixwin = clearwin_info@ ('graphics_width')
iywin = clearwin_info@ ('graphics_depth')
idimension = idimension + 1
if (idimension >= idimension_max) idimension = idimension_min
endif
call plot
end
!=======================================================================================================
subroutine plot
!=======================================================================================================
use module_resize
implicit none
include <windows.ins>
integer*4 :: k,ierr
allocate(ipoint_x (idimension), ipoint_y (idimension), stat=ierr)
ipoint_x(1:idimension) = ixwin - 100
ipoint_y(1:idimension) = iywin - 100
do k=1,idimension
call draw_rectangle@(x1,y1,ipoint_x(k),ipoint_y(k),rgb@(255,0,0))
call draw_line_between@(x1,y1,ipoint_x(k),ipoint_y(k),rgb@(0,0,255))
call draw_line_between@(x1,ipoint_y(k),ipoint_x(k),y1,rgb@(0,0,255))
enddo
deallocate(ipoint_x, ipoint_y, stat=ierr)
return
end |
|
|
| Back to top |
|
 |
Wilfried Linder
Joined: 14 Nov 2007
Posts: 314
Location: D�sseldorf, Germany
|
| Posted: Wed Mar 16, 2011 10:47 am Post subject: |
|
|
Hmmm... I copied your code, made one small change...
| Code: | !=======================================================================================================
winapp
!=======================================================================================================
program resize ! this I add
use module_resize
implicit none |
... then start
"c:\program files (x86)\silverfrost\ftn95\ftn95" /checkmate resize.f95 /link
... and everything is running. I have Windows 7 / 64 bits and the actual FTN95 version.
Regards - Wilfried |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Wed Mar 16, 2011 11:26 am Post subject: |
|
|
| Quote: | | Hmmm... I copied your code, made one small change... |
This does not change a bit on all systems I've tried.
| Quote: | | I have Windows 7 / 64 bits and the actual FTN95 version. |
We're using the current FTN95 version as well (v6.00) and tried several Win7 systems. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed Mar 16, 2011 1:47 pm Post subject: |
|
|
I have tired your code on my Windows 7 (64 bit OS) without any problem.
You could try removing the repeated ALLOCATE and use a maximum dimension instead (just to see it it makes any difference). |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Wed Mar 16, 2011 2:14 pm Post subject: |
|
|
| Quote: | | I have tired your code on my Windows 7 (64 bit OS) without any problem. |
So you get the expected red rectangle with diagonal blue lines, when compiling the source with checkmate? |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed Mar 16, 2011 4:36 pm Post subject: |
|
|
Yes but only when I click on the graphics region or after a resize.
Both presumably generate a resize command. The missing initial view can be fixed by plotting within a callback for %sc. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed Mar 16, 2011 4:39 pm Post subject: |
|
|
| Correction. I have to click in every case. Will try on XP. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed Mar 16, 2011 4:45 pm Post subject: |
|
|
| The behaviour is different under XP. You get the box and lines without clicking under XP. I can investigate to try to find out why the behaviour is different on the two operating systems. There is no problem running the app under Windows 7 for me but the behaviour is different. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Wed Mar 16, 2011 5:32 pm Post subject: |
|
|
This particular program does not need an array.
You only need one cycle of the do loop with the fixed boundaries for the rectangle.
I assume that the difference of behaviour for me between XP and Windows 7 is to do with the synchronisation of events under Windows (perhaps the drawing events are cached in some sense so that when the line is actually drawn the array is nolonger allocated for a resize but it is for a mouse click). This does not make a lot of sense to me but it would begin explain why the app fails on your machine.
Anyway, if you need to use an array then it looks like the storage needs to be more permanent.
By the way, ALLOCATE uses a different memory model for CHECKMATE so this is consistent with the above. |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Wed Mar 16, 2011 11:13 pm Post subject: |
|
|
| Quote: | | There is no problem running the app under Windows 7 for me but the behaviour is different. |
The fact that there is a difference when running this program under different operating systems IS a problem.
| Quote: | | This particular program does not need an array. |
This is a highly reduced program to depict the core of a problem. I assure you the program does need an array, in fact newer versions tend to use dynamic memory allocation a lot more because of the added flexibility.
| Quote: | | Anyway, if you need to use an array then it looks like the storage needs to be more permanent. |
I don't see any programming error, and the test application works as expected (using checkmate, using debug mode as well as release) under XP.
To maybe get a better idea of the problem check the drawing routine in SDBG, namely put a breakpoint on the line that performs the allocate and on the line following the allocate. Note that ONLY the first breakpoint is ever hit, for some reason the ALLOCATE statement prematurely exits the drawing routine (whatever, it's not clear to me what happens even when looking at this in the SDBG disassembly view since it happens in one of the called internal routines).
| Quote: | | perhaps the drawing events are cached in some sense so that when the line is actually drawn |
See above, the drawing routines are never even reached using a checkmate build.
Thanks for reporting back on this, if you need more information or have any hints please let me know. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Thu Mar 17, 2011 9:14 am Post subject: |
|
|
| I will investigate further but in the meantime you should switch off /check in the locality of the ALLOCATE. That is, just use /DEBUG localy. |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Thu Mar 17, 2011 9:23 am Post subject: |
|
|
| In the full application the problem intermittently occurs in release and debug compiled executables as well, but extracting a simple example is very hard for those cases. |
|
| Back to top |
|
|
sparge
Joined: 11 Apr 2005
Posts: 371
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8211
Location: Salford, UK
|
| Posted: Thu Mar 17, 2011 11:17 am Post subject: |
|
|
The problem is somewhere in the internal memory allocation process for /check mode. As far as I know it only concerns 64bit Windows 7 and this kind of usage of ALLOCATE.
There is nothing you can do except wait for a fix from us except to use /debug locally instead of /check (or anything that implies /check). |
|
| Back to top |
|
|
Sebastian
Joined: 20 Feb 2008
Posts: 177
|
| Posted: Thu Mar 17, 2011 11:21 am Post subject: |
|
|
I was hoping that the problem would *not* be limited to checkmate (just visible only in the example when using checkmate), if there's any progress or you think some changes can be tested that could have an effect on release/debug builds as well, please let me know. Also if you have details on why the allocate can abort the drawing function, please acknowledge me (maybe it gives hints on what's happening in the real application).
Thanks for checking this out! |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
