CALLBACK_REASON response ? in %gr callback

I've been having quite a few problems moving over to FTN8.1 from 7.1. In this example I'm calling CLEARWIN_STRING@('CALLBACK_REASON') within a %gr callback and it is returning frequent '?' strings when clicking around within the area, particularly click and drag. It's not really a problem but the help states '?' means 'not in callback', and this behaviour doesn't occur in 7.1.

Here's a cut-down example:

! Demonstrates occasional return of '?' from CLEARWIN_STRING@('CALLBACK_REASON') when
! within%gr callback. Typically on click and drag within the gr
winapp
use mswin

integer:: gr_dx = 600;
integer:: gr_dy = 300;

external grCallback

i = winio@('%ww[no_border,independent,not_fixed_size]&')
i = winio@('%ca[FTN Test]%nd&')
i = winio@('%pv%`^gr[white,user_resize,full_mouse_input,rgb_colours]%nl', &
           gr_dx, gr_dy, 1, grCallback)
end

integer function grCallback()
  use mswin
  character*32 rstr

  rstr = CLEARWIN_STRING@('CALLBACK_REASON')
  if (rstr /= 'MOUSE_MOVE' .and. rstr /= 'RESIZE') print *, rstr(1:LEN_TRIM(rstr))  ! sometimes '?' which means 'not in callback'
  grCallback = 1
end function grCallback

This is compiling as x86 under Windows 10 so may well be a Win 10 issue, although it doesn't happen in Win 10 when compiled with FTN 7.1.

Alan

Alan, I don't know the answer to this, but I can replicate your issue in Windows 10. Seems to me that a left click is fine, a right click is fine too, but a simultaneous left and right click, i.e. finger trouble/big thumb on my keyboard touch mouse produces '?'.

Ken

I have made a note to revisit this issue to see if anything can be done.

Paul's use of the word 'revisit' indicates that this topic has been on the Forum before. The issue is the huge number of mouse interrupts when you use full_mouse_input. One of the best suggestions was to interrogate the mouse position and button states, and if nothing changed since the last interrupt, throw it away.

Eddie

This issue has now been fixed for the next release of the ClearWin+ DLLs (the one after the full release of FTN95 v8.20).

I've just upgraded to 8.30. In the test program I don't see '?' any more but I'm finding the mouse messages are now very unreliable, in particular when a click is combined with a move (make click and drag tricky!).

So using the same test program if I perform a simple left click I get the expected click and release but if I click and drag at the same time I will sometimes only get the click, sometimes no click and only release, and sometimes nothing at all. Particularly if I do it quite quickly. It does seem to perform differently with different mice, but I don't have any such problems with older versions of FTN95. Any thoughts?

I think that this is now OK in the latest beta download...

https://forums.silverfrost.com/Forum/Topic/3403

Thanks Paul. Unfortunately that doesn't seem to make a difference. It's definitely related to moving the mouse at the same time as the click or release. If I keep the mouse still then everything is as expected, if I move as I click or release no click or release message comes through. It seems to be okay (or at least far more reliable) with middle mouse clicks but left and right don't come through at all when moving.

This is on a Win 10 machine, it also seems to do it, although nowhere near as much, running a win 8.1 VM.

I suspect unrelated but I also note that the (cross-hair) mouse cursor is invisible in some situations: I have a multi-monitor setup on win10 (with different scaling for each monitor) - on some screens I see the cursor in the window, on others it is not drawn. Makes no difference to the click operation.

If you can send me some sample code then I will take another look at it. There are a large number of mouse move messages and it will depend on how much processing your callback is doing. ClearWin+ has its own message buffer for this purpose and maybe the size of this buffer could be under user control. Another possibility is to make sure that only mouse move messages are lost.

Yet another way could be to get ClearWin+ to wait but that could easily cause other problems.

The code is the same code that is at the start of this thread. Mouse moves are filtered so it will generally only show the click & release events. It works fine with FTN 7.1.

With full_mouse_input the system is overflown with the interrupt requests while older requests are still not finished. It's like watching football on car monitor, texting and drive & drink at the same time. Makes a mess like reported above or crashes in more complex cases.

This fix below prevents callback to start new request before previous one was completed. Controlled by introduction of global variable k_CB_busyRunning which is set =1 when callback starts and =0 when it ends. I always use it with full_mouse_input.

winapp 
use mswin 

integer:: gr_dx = 900; 
integer:: gr_dy = 600; 

external grCallback 
common /CB_busyRunning_/ k_CB_busyRunning

k_CB_busyRunning= 0
iTextOutpUnit   = 2

i = winio@('%ww[no_border,independent,not_fixed_size]&') 
i = winio@('%ca[FTN Test]%nd&') 
i = winio@('%pv%`^gr[white,user_resize,full_mouse_input,rgb_colours]%ff&', & 
           gr_dx, gr_dy, 1, grCallback) 
i = winio@('%`bg%100.9cw[hscroll,vscroll]%es', rgb@(234,234,255), iTextOutpUnit)
end 

!----------------------------
integer function grCallback() 
  use mswin 
  character*32 rstr 
  common /CB_busyRunning_/ k_CB_busyRunning

  if(k_CB_busyRunning.eq.1) goto 10000
     k_CB_busyRunning  = 1

  rstr = CLEARWIN_STRING@('CALLBACK_REASON') 
  if (rstr /= 'MOUSE_MOVE' .and. rstr /= 'RESIZE') print *, rstr(1:LEN_TRIM(rstr))  ! sometimes '?' which means 'not in callback' 

     k_CB_busyRunning = 0
10000  grCallback = 2 

end function grCallback 

The 'callback reason' with '?' should no longer happen. If you have code that gives this reason and you are using the latest beta download then please send me a demo.

Also if there is a crash and you are confident that the fault lies in ClearWin+ then, again, please send a demo.

The strategy that Dan uses is a good idea but will mean that events reported when k_CB_busyRunning is 'true' will not processed. This may, for example, be OK for 'mouse move' but not for 'mouse click'.

Indeed, this time i was unable to crash it. Before if the callback was performing print* while another process was trying to do the same at the same time, the code crashed. Clearwin+ behaved this way (with no crash) at the beginning, around year 2000, but around 2010 it started crashing. Was some bug found in Clearwin or some special care was taken for threads or print streams not to interfere?

The code at the top of the thread is the code I am using to test. I can supply the exe if it helps. ? no longer appears but clicks are missed - my output shows intermittent left mouse click/release if the mouse is moving (even slowly). Processing speed should not be an issue in this case as mouse moves are filtered and as you say Paul, ignoring if already busy will just miss mouse events. Is this actually possible anyway? With a single window one would typically have a single UI thread with a single message queue and message loop so only one message will be handled at a time. The message queue might fill up but I didn't think we could get re-entrant behaviour.

I've just double-checked on FTN7.10 and it works fine - in fact if I take the same exe (compiled on 7.1 or 8.3) and use the FTN7.1 version of salflibc.dll it all works, then just change to the 8.30 (or beta) salflibc.dll and it starts causing the problem.

I've now tested on two Win 10 machines, a Win 8.1 and Windows 7 machine and the all exhibit the same problem, irrespective of the type of mouse. Just move the mouse (even slowly) and click while moving and no click messages appear.

I have had another look at this. For me, the mouse button release event is not always getting through to the callback after a rapid mouse move.

At the moment I don't know how to fix this assuming that re-entry into the callback is not permitted.

A temporary_yield within ClearWin+ is not relevant. I could possibly post a message back into the message queue but then it would be out of order.

If you are not interested in mouse move events then I could possibly provide an option to filter them out at source. This would presumably fix the problem for some users.

Thanks Paul. In this case our large CAD application is based around the message loop to provide lots of click and drag type operations (zoom, select etc.) so relies on the click and release events. It also relies on move although if the odd move is missed that is no great drama.

Is this down to some fundamental redesign of message handling within ClearWin? Our app has worked for years and years with regular FTN95 updates.

Alternatively is there any way I can get access to the underlying message loop, %mg(WM_LBUTTONDOWN) doesn't work, presumably ClearWin gets in there first.

I'm finding that it doesn't really need to be a fast mouse move - just moving is slowly with a click and release has problems. I'm still puzzled why there would be re-entrancy anyway, given I thought Windows only sends the message to the single UI thread?

I don't know why it worked before and not now. I have worked out how to store one pending message and this helps but does not solve the problem completely. I will have a go a creating a list of pending messages for stacked up mouse events.

Please try the following download to see if it fixes the problem.

https://www.dropbox.com/s/eg9llf9lvytxrfr/acw.zip?dl=0

Great, thanks Paul. That does appear to fix the example and makes a massive difference to our main app although I am still getting a few ? reasons in the main app and always at startup after the initial RESIZE. Sometimes the first mouse click is not reported but after that is is pretty solid.

If I add some re-entrancy detection I am finding a few re-enters on MOUSE_MOVES and MOUSE_WHEEL events. Looking back at older versions this has always been the case and hasn't caused problems although I do allow for it. With the latest salflib some of the re-entrant messages are ?s.