Digit dropping in %rd and 5rf boxes with %il in operation

I have a block of code in a program that looks like this:

      DO 20 I=1, No_Of_Nodes
      IA=WINIO@('%nl&')
      IA=WINIO@('%co[check_on_focus_loss]&')
      IA=WINIO@('%`bg[window]%`rs   &', PQ(I))
      IA=WINIO@('%il%`bg[window]%^rd%`il°%ta  &', 
     &           0,359,MD(I), ISUM_ANGLES)
      IA=WINIO@('%il%`bg[window]%^rd%`il''  &',   
     &           0,59, MM(I), ISUM_ANGLES)
      IA=WINIO@('%il%`bg[window]%^rd%`il'  &',    
     &           0,59, MS(I), ISUM_ANGLES)
      IA=WINIO@('%co[full_check]&')
      IF (I .EQ. No_Of_Nodes) GO TO 20
      IA=WINIO@('%2ta%`bg[window]%`rs and %`bg[window]%`rs%ta&', 
     &          PQ(I), PQ(I+1))
      IA=WINIO@('%`bg[window]%^rf (m)&', DIST(I), ISUM_ANGLES)
  20  CONTINUE

PQ is an array of 4-char names, MD, MM, MS are arrays of degrees, minutes and seconds, DIST is an array of distances which may have a decimal part, and because of the nature of the problem, one distance is known so I have input of one less distance than the number of angles. ISUM_ANGLES is a callback that sums the angles and compares to the (2n+4) right angles around the outside of a polygon. It also checks that none of the distances are zero or negative, and if these criteria are met, a button is un-greyed so that the computation may progress.

If the %co codes are omitted, some of the boxes have a nasty habit of losing their last digit when the user is entering data in a different box. Needless to say, this is irritating in the extreme. If the %co[full_check] code is where I have it (above), this behaviour occurs in the DIST boxes, but not the MD, MM or MS boxes. If I pull both %co codes outside the loop, then the digit-dropping doesn't occur - but then the focus is never lost from the last box, whatever it is, and the elegance of revealing the 'continue' button is lost.

I suspect that the answer is to hang the ISUM_ANGLES callback onto a %dl with an appropriately short delay, but it is late and I may try that in the morning.

I normally don't get on well with %il, and usually check the limits myself in a callback when the need arises. Perhaps this is one of those cases where I need 2 callbacks. I did note that taking %il out from the degrees (MD) box changes its size, which is also rather frustrating, but no doubt I can get the sizes right again with %nrd etc and a bit of trial and error.

I would be very grateful if anyone can shed light on this behaviour, or even better, its solution.

(Using 32bit Win7 and v6.10)

Eddie

Eddie,

I tried to run your code, see below, and I don't get any problems. May be you can give more information about them? Does my code make problems on your PC?

Regards - Wilfried

      WINAPP

      program test

      IMPLICIT NONE
      INCLUDE <WINDOWS.INS>

      external      isum_angles

      integer*4     MD(10),MM(10),MS(10)
      integer*4     i,ia,isum_angles,no_of_nodes
      real*8        DIST(10)
      character*20  PQ(10)

      MD = 0
      MM = 0
      MS = 0
      PQ = 'text      '
      DIST = 4711.D0
      no_of_nodes = 3

      IA = WINIO@('%ca[Test]&') 
      DO I = 1,No_Of_Nodes 
        IA = WINIO@('%nl%`bg[window]%`rs&', PQ(I)) 
        IA = WINIO@('%il%`bg[window]%^rd%`il°%ta  &', 
     &              0,359,MD(I), ISUM_ANGLES) 
        IA = WINIO@('%il%`bg[window]%^rd%`il''  &',    
     &              0,59, MM(I), ISUM_ANGLES) 
        IA = WINIO@('%il%`bg[window]%^rd%`il'  &',    
     &              0,59, MS(I), ISUM_ANGLES) 
        IF (I < No_Of_Nodes) THEN
          IA = WINIO@('%ta%`bg[window]%`rs and %`bg[window]%`rs%ta&', 
     &                PQ(I), PQ(I+1)) 
          IA = WINIO@('%`bg[window]%^rf (m)&', DIST(I), ISUM_ANGLES) 
        END IF
      END DO
      IA = WINIO@('%ff%nl%cn%`7bt[OK]') 
      end

c ------------------------------------------------------------ c

      integer  function isum_angles()

      IMPLICIT NONE

      isum_angles = 1
      end

Wilfried,

Your example works fine, but then sometimes these foibles only show in larger programs. I've been through the callback and although MD etc are used, they are not altered. At least it is not a problem intrinsic to %il.

By the way, thank you for the fragrant hint that you are based in Köln!

If I do discover the answer, I'll post it, as I remember around 2005/6 something similar (again with angles) that I solved pro tem by doing the limits checking myself.

Eddie

After a certain amount of experimentation, I have made the issue disappear. A partial solution was obtained by reducing the amount of computation in the callback function, removing a bit of elaborate trigonometry that in all fairness needed to be done only once anyway, and putting that in a separate callback to %sc. That improved matters up to the point that the dialog could, in fact, be used without provoking an outburst of Tourrette's Syndrome on the part of the user (most of the time).

The real answer, and the complete solution, was that I had used UPDATE_WINDOW@ instead of WINDOW_UPDATE@. As I was updating integers, UPDATE_WINDOW@ just accepted them as handles, and did not protest.

I observe that while UPDATE_WINDOW@ merits mention in the 'Library reference', WINDOW_UPDATE@ does not, and it must be hunted for. I suggest that WINDOW_UPDATE@ is important enough to mention a place in said 'Library reference'.

Eddie