Is this my computer fault?

If this code run as is the progress bar stops in the middle. If run via debugger it works fine to the end

   use clrwin 
   real*8 Progress 

   Progress = 0 
   i=winio@('Progress E %15br%ff&', Progress, RGB@(255,88,60)) 
   i=winio@('%cn%es%bt[OK]%lw',ilw) 

   aa = 3.14 
   iYmax = 1000000    

   DO iY=1, 200000000    
    aa=alog(exp(aa) ) 
    if(iY/iYmax*iYmax.eq.iY) then 
       Progress = iY/200000000. 
       call window_update@(Progress) 
       print*,' iY=', iY 
     endif 
   enddo 
   END

No, mine runs it right through. (AMD Phenom II, 16Gb)

Eddie

ok for me too! - Win 8.1/intel i5 - 4570

Brian

Thanks, so i went to reboot computer and the bug is gone. What may cause this?

Dan, I can't see any error, but I simplified your stepping test. use clrwin real8 Progress , aa integer4 i, ilw, iYmax, iY, next, step, limit integer*4 :: million = 1000000

    Progress = 0 
    i = winio@ ('Progress E %15br&', Progress, RGB@(255,88,60)) 
    i = winio@ ('%ff%cn%es%bt[OK]%lw',ilw) 

    aa    = 3.14 
    limit = 200*million
    step  = million
    next  = 0

    DO iY = 1, limit
     aa = alog (exp(aa) ) 
     if (iY >= next) then 
        Progress = iY/real(limit)
        call window_update@ (Progress) 
!z        print*,' iY=', iY 
        next = next + step
      end if 
    end do 
    END

There was no source error but some corruption somewhere in OS or in the compiler which turned FTN95 into the insane state. Do you sometimes feel something wrong after very long period of time not rebooting computer? In DOS times that was a norm, right now this happen ones per year of heavy use.

I've also seen the bar stop updating. And I have a way around it that worked for me. BTW, in my case, the bar stopped updating, but the underlying code ran to completion.

In my case, if I prevent the updates from occurring too fast (i.e. increase the time between successive calls), the bar works perfectly. I always call the routine, but look at the elapsed time between subsequent calls, and ignore updating the window too quickly.

In my case, I update every second (a convenient value for my application). Also, for my application, I close the status bar window at the end of it usefulness, so I know the code is still running through to the end, regardless of what the bar status actually says.

I have run across other cases where, if you do things too fast, the ClearWin+ functions don't have enough time to 'clean up' from the previous call, and it can cause a crash.

I've included the code I use here. The first call (NCUR=0) initializes the window, and NCUR=-1 to close it. YMMV.

	SUBROUTINE STATUS_BAR(text,NMIN,NMAX,NCUR)
	INTEGER NMIN,NMAX,NCUR
	character*(*) text ! for labelling the status bar
	REAL*8 FILL
	real*8 fill_last,fill_this
	INTEGER*4 WINDOW_HANDLE,RGB@,ICOLOR
	INTEGER*4 WINDOW_CLOSURE
	COMMON/STATBAR/WINDOW_HANDLE,WINDOW_CLOSURE
C --- PREVIOUSLY NOT DECLARED
	INTEGER K
C --- INITIALIZE THE STATUS BAR WHEN NCUR = 0
	IF(NCUR.EQ.0) THEN
	   ICOLOR = RGB@(0,255,0)
	   FILL = 0.0
	   WINDOW_HANDLE = 0
	   WINDOW_CLOSURE = 0
	   k = winio@('%ca@&',text)
	   K=WINIO@('%nl%40br[no_border,left_right,percentage]&',
     $		FILL,ICOLOR)
	   K=WINIO@('%hw&',WINDOW_HANDLE)
	   K=WINIO@('%lw',WINDOW_CLOSURE)
	   call dclock(fill_last)
	ELSE
	   IF(NCUR .EQ. -1) THEN
	      WINDOW_CLOSURE = 0
	      CALL WINDOW_UPDATE@(WINDOW_CLOSURE)
	      CALL SLEEP1@(1.)
	      RETURN
	   ENDIF
C --- NCUR IS >0
	      call dclock(fill_this)
	      if(fill_this-fill_last.le.1.d0) return
	      fill_last = fill_this
	      FILL=DBLE(NCUR-nmin)/DBLE(NMAX-NMIN)
	      IF(FILL.GT.1.0D0)FILL  = 1.D0
	      if(fill.lt.0.0d0) fill = 0.0d0
	      CALL WINDOW_UPDATE@(FILL)
	      call sleep1@(1./15.)
	ENDIF
	RETURN
	END

The final SLEEP1@ call was added to make sure the window has released all its resources just in case that another Status Bar is immediately created.