Richard made the points below relating to my last post: His comment about using ON MOUSE in conjunction with subsequent MOUSE x,y,z statements to determine the "mouse up" situation is exactly what I had in mind, but should perhaps have made more explicit. My comments on interrupts were drawn essentially straight from the manual, and were meant as a general caution about using interrupts, but I can see that in this situation it is unlikely to be an issue.
> The event is generated by PRESSING the button, not by releasing it.
> Most software uses the position where you RELEASE the button to determine what happens
Whilst that is true, it isn't a reason not to use ON MOUSE. In applications like the Calculator, when a single click of the mouse (or tap of the finger) needs to result in *exactly one* action, ON MOUSE is the only acceptable approach.
This fundamentally comes down to the difference between a 'state' and an 'event'. The 'MOUSE x,y,b' statement tests the state of the mouse, specifically whether a button is currently pressed or not. This means that, depending on how long you keep the mouse button pressed, it may not be detected at all (if the button is pressed for a time shorter than the period between two consecutive MOUSE statements) or it may be detected multiple times (if the button is pressed for a longer time).
There is simply no way that, by polling with MOUSE, you can reliably detect a single press, just once, irrespective of how short or long a time it is kept pressed, which is what you need for a calculator. What you should be responding to is an event and not a state, and in BB4W and BBCSDL the statement which detects a mouse event is ON MOUSE: it is guaranteed to activate its handler just once for each individual mouse click.
If you are concerned that the action should take place on releasing rather than on pressing the mouse button (and I'm not convinced that it is as essential and universal as you suggest) then you can easily achieve that by using ON MOUSE in conjunction with a subsequent MOUSE.
When the ON MOUSE event has detected the press you can spin in MOUSE until you see that the button has been released; the 'exactly one event for each click' behaviour can be maintained.
If the implication is that ON MOUSE works incorrectly, and should trigger its event on a release, I would point out two things. Firstly, it has worked the same way since BB4W was first released, nearly 17 years ago, and I don't remember anybody having made that criticism before. Secondly, generating an event only on release would be less flexible because if you wanted to take some action on the press you couldn't (of course ON MOUSE could have generated an event on both press and release, but that would make it trickier to use).
> Using the interrupt routines only takes effect after the completion of the current BASIC command, so if you are in the middle of a WAIT/INPUT/INKEY/GET/SOUND etc there may be a delay which may not be appropriate
I'm afraid that doesn't make much sense to me. We are discussing the pros and cons of using ON MOUSE rather than MOUSE. If you are polling the state of the mouse using 'MOUSE x,y,b' then not only will the click not be detected until the end of the current statement, it won't be detected until the next MOUSE statement is executed (or indeed it may not be detected at all: an 'infinite' delay): the potential for an 'inappropriate' delay is therefore much *greater* than it is with ON MOUSE, not less!
If the delay resulting from ON MOUSE is unacceptable I don't know what alternative you are proposing, because there is no mechanism available to you in BBC BASIC to reduce it any further. You could perhaps run an assembly language routine in a high-priority thread, but even if that can detect a mouse click with less latency what is it supposed to do with it once it has happened?