forums.silverfrost.com

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

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:

Kenneth_Smith · Posted: Mon May 08, 2017 9:27 pm Post subject:

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

PaulLaidler · Posted: Tue May 09, 2017 7:04 am Post subject:

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

LitusSaxonicum · Posted: Tue May 09, 2017 2:16 pm Post subject:

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

PaulLaidler · Posted: Thu Nov 09, 2017 1:49 pm Post subject:

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

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

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?

PaulLaidler · Posted: Mon Jul 09, 2018 9:54 pm Post subject:

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

http://forums.silverfrost.com/viewtopic.php?t=3827

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

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.

PaulLaidler · Posted: Tue Jul 10, 2018 9:44 pm Post subject:

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.

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

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.

DanRRight · Posted: Wed Jul 11, 2018 5:24 am Post subject:

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.

PaulLaidler · Posted: Wed Jul 11, 2018 6:53 am Post subject:

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".

DanRRight · Posted: Wed Jul 11, 2018 9:37 am Post subject:

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?

acw · Joined: 04 Nov 2005 Posts: 165 Location: Darkest Devon

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.

PaulLaidler · Posted: Wed Jul 11, 2018 1:10 pm Post subject:

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.