Window closure puzzle

I have been seeing some unexpected behaviour in one of my applications when a window is closed manually (everything is fine if the window is closed under program control). So I tried to reproduce the problem in a small illustrative app. I failed (so far), but got some equally unexpected behaviour - leading me to wonder if what I am seeing in the real app is just the same problem manifesting differently in a more complex environment.

In the code below, clicking Load opens a graphics region (having checked to to see if one is already open, and closing it if so) i.e. clicking Load repeatedly should repeatedly open and close a single graphics region window. This window should also be closable by clicking at top right. If the graphics window code uses %cc as a closure control, it gives a floating point stack overflow in the closure control callback where it calls clearwin_info@; and if it uses %`cc as a closure control, the closure control callback does not get called at all. Both outcomes are unexpected (by me anyway) 😃 It doesn't matter if the graphics window is closed manually or under program control.

I should say that the original program can have multiple graphics region windows open with associated memory that needs to be freed up, hence the closure control code is rather OTT in this case.

What is going on here?

Andy

    program gaga
    use callbacks
    integer iomain
    radio1 = 1
    radio2 = 0
    ptrgra = 0
    iomain = winio@ ('%lw&', cvmain)
    iomain = winio@ ('%cn%^bt[Load]&', setgra)
    iomain = winio@ ('%ff%nl%fr', 200, 200)
    stop
    end program gaga

    module callbacks
    integer cvmain, radio1, radio2, iograp, ptrgra, grawid, hanwin, ctrwin
    contains
    integer function setgra ()
    setgra = 2
    if (ptrgra .ne. 0) then
      ctrwin = 0
      call window_update@ (ctrwin)
    end if
    grawid = 100
    iograp = winio@ ('%gr[user_surface]&', grawid, grawid, ptrgra)

! iograp = winio@ ('%`cc&', auto_clowin) iograp = winio@ ('%cc&', auto_clowin) iograp = winio@ ('%hw&', hanwin) iograp = winio@ ('%cv&', ctrwin) iograp = winio@ ('%aw', cvmain) return end function setgra integer function auto_clowin () integer hanwincur auto_clowin = 0 hanwincur = clearwin_info@ ('CALL_BACK_WINDOW') if (hanwincur .eq. hanwin) call clowin (hanwincur) return end function auto_clowin subroutine clowin (hannom) integer hannom do if (hannom .eq. 0) exit ! do-nothing if nothing to do if (hannom .ne. hanwin) exit ! do-nothing if window handle is unexpected hanwin = 0 ptrgra = 0
exit ! on normal completion end do return end subroutine clowin end module callbacks

Seeems this one got lost in the mix. Ho hum. In the meantime, I've half-answered the question I posed - if the line 'use clrwin' is included, the floating point stack fault does not occur.

I've never been clear when it is and isn't necessary to 'use clrwin' - advice please?

Also, it is still the case that if %`cc rather than %cc is used, it does not get called - seems like a bug.

Anyway, I've now got code that illustrates the unexpected behaviour I mentioned in the first post. Here it is. The single menu item Read opens a %gr window (having checked for the presence of a previous one, and closed it if so). If this closure before reopening is effected under program control, nothing goes wrong. **If however, the window is closed manually, the radio button pair is toggled, unbidden. **After the first time, the behaviour does not seem to reoccur (unlike my real app, where it seems to occur repeatedly but unpredictably).

Andy

  winapp 0, 0
  program radio_gaga
  use utilities
  integer iomain

! initialise variables calibrating = 0 measuring = 1 ptrgra = 0 ! main window iomain = winio@ ('%ww&') iomain = winio@ ('%cv&', cvmain) iomain = winio@ ('%mn[~Read]&', measuring, makgra) iomain = winio@ ('%2ga&', calibrating, measuring) iomain = winio@ ('%^rb[Calibrating]&', calibrating, update_menu) iomain = winio@ ('%^rb[Measuring]&', measuring, update_menu) iomain = winio@ ('%ff%nl%bg[grey]%fr', 150, 150) stop end program radio_gaga

  module utilities
  integer calibrating, measuring, cvmain, iodial, ptrgra, ctrwin, hanwin
  contains

!-------------------------------------------------------------------- integer function makgra () makgra = 2 if (ptrgra .ne. 0) then ctrwin = 0 call window_update@ (ctrwin) end if iodial = winio@ ('%ww[no_border,no_maxminbox]&') iodial = winio@ ('%gr[black,user_surface]&', 100, 100, ptrgra) iodial = winio@ ('%cv&', ctrwin) iodial = winio@ ('%hw&', hanwin) iodial = winio@ ('%aw&', cvmain) iodial = winio@ ('%cc', auto_clowin) return end function makgra !------------------------------------------------ integer function auto_clowin () auto_clowin = 0 hanwin = 0 ptrgra = 0 return end function auto_clowin !------------------------------------------------ integer function update_menu () update_menu = 2 call window_update@ (measuring) return end function update_menu !------------------------------------------------ end module utilities

Andy

I did see your forum item but I simply haven't had the time to respond. Your questions tend to be quite deep and can take an hour or so to investigate. The advice given here is free so complex questions may not get a quick response.

Regards

Paul

Hi Paul,

I do understand your difficulty. I'm not just looking for free advice - I'm as certain as I can be that this is a bug. Should I have just submitted the code to ftn95@silverfrost.com (as I tend to do that with suspected compiler bugs)?

Andy

Andy

You can leave the issue here if you wish.

Andy

The original problem was probably that clearwin_info@ needed to be declared as returning an integer. There is no clear cut rule about when you need 'use clrwin'. The source code for the module is provided so you can see what is defined in it. The corresponding include file provides an alternative way to get this information.

I agree that %`cc does not work in this context but I do not know why. Please let me know if this is important, i.e. that you need this feature and you cannot find an alternative way of getting what you want.

The problem with the radio buttons must be something to do with the way that %ga works (or does not always work in this case). %ga is one of those features which is OK if it works for you, otherwise it is better to provide the toggle directly in your code via a callback function. In other words, I am not offering to fix %ga.

Regards

Paul

Thanks for looking at this, Paul.

The original problem was probably that clearwin_info@ needed to be declared as returning an integer. There is no clear cut rule about when you need 'use clrwin'. The source code for the module is provided so you can see what is defined in it. The corresponding include file provides an alternative way to get this information.

OK - not including 'use clrwin' in my original post was an oversight on my part. But why do neither the compiler nor the linker female dog about clearwin_info@ not being declared when that line is omitted?

I agree that %`cc does not work in this context but I do not know why. Please let me know if this is important, i.e. that you need this feature and you cannot find an alternative way of getting what you want.

No - it's not important. I only tried it in case there was some subtlety of timing that meant I was using the wrong variant. Having discovered that it didn't work, I reported it on the assumption that you would want to know about it.

The problem with the radio buttons must be something to do with the way that %ga works (or does not always work in this case). %ga is one of those features which is OK if it works for you, otherwise it is better to provide the toggle directly in your code via a callback function. In other words, I am not offering to fix %ga.

OK, if that's the root of the problem, I can provide code to fix it. Perhaps %ga should come with a 'use at your own risk' warning - you seem to be implying that it's known to be 'temperamental'.

Andy

By the usual Fortran default, the compiler assumes that clearwin_info@ returns a default REAL (from the implicit range of the first letter). The linker finds the routine in salflibc.dll but links it as returning an INTEGER*4. Everything works OK until the two conflict at runtime. To resolve the problem the compiler needs to know the correct return type. You can provide this information directly in the code or 'USE clrwin'.

Paul,

Apologies if I'm being dense here, but ... I have the compiler switch /IMPLICIT_NONE in my FTN95 config file. Why does that not prevent the compiler from making the default type assumption about clearwin_info@?

Andy

Quoted from PaulLaidler The problem with the radio buttons must be something to do with the way that %ga works (or does not always work in this case). %ga is one of those features which is OK if it works for you, otherwise it is better to provide the toggle directly in your code via a callback function. In other words, I am not offering to fix %ga. Paul

Paul,

I have now modified the code, commenting out the %ga format code in order to (try and) take full explicit control of the two radio buttons - see attached - and the issue remains. The first time the graphics region window is closed manually i.e. by clicking at top right, the radio buttons are toggled by some invisible callback process. Subsequently, the code works as expected. In my real application, however, the toggling happens repeatedly but not repeatably i.e. not just the first time the window is closed manually, but not every time.

It seems that it is not the gang format that is responsible. On the grounds that I don't see what more I can do to code around the problem, I am reporting this as a bug for investigation, please. I have sent a zip of the code to ftn95@silverfrost.com.

Andy

Quoted from sparge Paul,

Apologies if I'm being dense here, but ... I have the compiler switch /IMPLICIT_NONE in my FTN95 config file. Why does that not prevent the compiler from making the default type assumption about clearwin_info@?

Andy

I guess that /IMPLICIT_NONE does not relate to the names of subprograms. We used to have /DCLVAR but this has not yet been implemented in FTN95.