Active Forums => QB64 Discussion => Topic started by: krovit on November 01, 2021, 06:29:18 pm
Title: Click
Post by: krovit on November 01, 2021, 06:29:18 pm
Hello everyone,
the question of controlling the click and double click of the mouse I had solved with the code that follows. The function is called to capture the double click.
It's probably not a great code either but it worked until version 1.6 of QB64. I upgraded to version 2.1 of QB64 but the compiler stops and reports this error (see image).
Missing elements of program, the IDE is red lining at line 6 because subroutine, fine, not present.
QB64 Version 2.1 does not exist, maybe you mean 2.01?
Technically neither does 2.01, as its actually 2.0.1 But oddly enough if you look at his screen cap it does say V2.1? 🤷♂️
Title: Re: Click
Post by: bplus on November 01, 2021, 08:03:49 pm
Well I got all the digits right ;-)) [ This attachment cannot be displayed inline in 'Print Page' view ]
BTW my screen says v2.0
Title: Re: Click
Post by: Pete on November 01, 2021, 11:41:59 pm
I use a timer for detecting double clicks, too. https://www.qb64.org/forum/index.php?topic=4262.msg136424#msg136424
There are many ways to code this, but the #1 criteria is, does it work?
Pete
Title: Re: Click
Post by: SMcNeill on November 02, 2021, 12:29:35 am
FUNCTION plusClick%(t1#) . . ...STUFF . . LOOP until plusClick% or provj$<>"" or provxxw&<>0 or _MOUSEWHEEL <> 0
The issue lies in the above. plusClick is your function name, and the glitch where you could use it in such a manner has been fixed. You're now trying to recursively call your routine over and over, and that no longer works.
You'll need to assign a temp variable to the code, inside the FUNCTION routine, instead of using plusClick% itself, until you get to the final assignment where plusClick = *whatever*.
Title: Re: Click
Post by: krovit on November 02, 2021, 04:31:42 am
Thanks Pete, I will also check your interesting method.
The proposed solutions work.
In short, it is a matter of avoiding "shortcuts" and sliding routines and functions in a linear way, without jumps.
However, I confess, I am worried!
The solutions don't seem to solve what seems to be a compiler problem.
In fact, filed the problem of this post, the compilation went on BUT stops countless times showing the same error message "Incorrect number of arguments passed to function".
The error occurs on rather trivial single commands, related to the execution of functions (these, perhaps, I will have to review them considering what has been said before) but also on the simple command SWAP (inside a function)
In short... something has changed since version 1.6 and 2.0.1. (2.1 in the window). The compiler now seems more attentive to the flow of instructions, as well as syntax, as is normal for us to be. The problem - if there is, but I think so - is how the compiler treats the code associated with the functions. Checking all the code inside the functions is not easy (there are many!) and above all it is not easy to understand how the compiler "reasons" now to avoid errors in the future.
Sure, I could continue with the 1.6 but it's not a good policy to ignore the updates and improvements.
Title: Re: Click
Post by: SMcNeill on November 02, 2021, 05:03:10 am
Think of it as writing a function for COS...
Function COS (angle)
DO ...some math LOOP UNTIL COS = whatever
Now, it's obvious here that COS is a function that we all know and love... The LOOP UNTIL COS = whatever line is going to error out on us, obviously. Right? After all, we didn't tell it what angle we wanted to use with the function COS (angle).
You're doing the *exact* same thing with your custom function:
FUNCTION plusClick%(t1#)
DO ...STUFF LOOP UNTIL plusClick% <> 0
plusClick is a function which wants a (t1#) passed to it. Where's the (t1#) that you're passing to the call to the function in the LOOP UNTIL line??
You're calling the function without passing it any value for the parameter, thus the "Incorrect number of arguments passed to function" error.
Title: Re: Click
Post by: Pete on November 02, 2021, 08:16:40 am
This one is interesting in a lot of ways.
1) Before version 2.0 the IDE allowed the parameter to be absent. I would not have expected it to miss that coding error. I guess this part of the break in function warning issued with this newer release.
2) Before version 2.0, the code, as written, would run without crashing. Now, unless the recursive function calls are fixed, as in my remake, below, the recursive calls in the Click% function cause it to crash.
3) The modified code works, but just as in the original code, it does not disallow for the reporting of a double click from more than the same button. In other words, we can get a recorded double click by clicking left then right, left then middle, or middle and right or middle and left. Also, it will report a double click if we hold a mouse button down and then release and quickly click it. This is not a traditional double click, at least not in Windows systems.
Anyway, if it helps, here is the modified code, which will run n V2.0...
Now if you will excuse me, I have to get back to my work in the Virginia Governor election. I've made 1,000 phone calls so far. I would have made more, but on that one-thousandth call, Steve finally figured out it was me calling each time, and shut off his phone!
Pete
Title: Re: Click
Post by: krovit on November 03, 2021, 03:12:29 am
Ah Pete! Real life! Incredible... there is also that...
Thank you for your time and valuable information
I believe that the problem lies in recursiveness: it must be carefully avoided
Title: Re: Click
Post by: krovit on November 03, 2021, 08:32:27 am
To better clarify things I attach the small and stupid program that follows (and that is useless!) that is compilable with versions up to 1.61 but not with 2.01