forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CALLBACK_REASON response ? in %gr callback
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
acw



Joined: 04 Nov 2005
Posts: 163
Location: Darkest Devon

PostPosted: Mon May 08, 2017 3:39 pm    Post subject: CALLBACK_REASON response ? in %gr callback Reply with quote

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:
Code:

! 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
Back to top
View user's profile Send private message Visit poster's website
Kenneth_Smith



Joined: 18 May 2012
Posts: 190
Location: Glasgow, Scotland.

PostPosted: Mon May 08, 2017 9:27 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Tue May 09, 2017 7:04 am    Post subject: Reply with quote

I have made a note to revisit this issue to see if anything can be done.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1878
Location: Yateley, Hants, UK

PostPosted: Tue May 09, 2017 2:16 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Thu Nov 09, 2017 1:49 pm    Post subject: Reply with quote

This issue has now been fixed for the next release of the ClearWin+ DLLs (the one after the full release of FTN95 v8.20).
Back to top
View user's profile Send private message
acw



Joined: 04 Nov 2005
Posts: 163
Location: Darkest Devon

PostPosted: Mon Jul 09, 2018 5:48 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Mon Jul 09, 2018 9:54 pm    Post subject: Reply with quote

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

http://forums.silverfrost.com/viewtopic.php?t=3827
Back to top
View user's profile Send private message
acw



Joined: 04 Nov 2005
Posts: 163
Location: Darkest Devon

PostPosted: Tue Jul 10, 2018 5:55 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Tue Jul 10, 2018 9:44 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
acw



Joined: 04 Nov 2005
Posts: 163
Location: Darkest Devon

PostPosted: Tue Jul 10, 2018 10:03 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 1878
Location: South Pole, Antarctica

PostPosted: Wed Jul 11, 2018 5:24 am    Post subject: Reply with quote

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.

Code:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Wed Jul 11, 2018 6:53 am    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1878
Location: South Pole, Antarctica

PostPosted: Wed Jul 11, 2018 9:37 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
acw



Joined: 04 Nov 2005
Posts: 163
Location: Darkest Devon

PostPosted: Wed Jul 11, 2018 9:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5594
Location: Salford, UK

PostPosted: Wed Jul 11, 2018 1:10 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group