I test for keyboard.asyncControlKey to determine whether the right mouse button is used
This always returns false in a mousedrag, even with the control key held down.
Why doesnt keyboard.async … work during a mousedrag event?
Did you return True the MouseDown event?
It works for me dragging + keyboard.asyncControlKey
Yes.
And it works on the Mac
But on Windows, nope.
Ive worked around it (kinda) by checking for .iscontextual in the mousedown event
and then storing whether the <key was pressed/right button held> when the mouse went down in a class level boolean.
Even if you could access Ctrl key, it does not work like the Mac where indeed that means right button. On PC, it does not do the same.
As System.MouseDown does not discriminate between buttons, what you did is I think the only way.
Indeed.
Digging around I find that I was logging queries about this on the old forum more than 7 years ago.
This is a case where the function is definitely Mac led.
On all other windows development tools I have used, mouse events supply a parameter that is a bitwise representation of the mouse button states.
By examining the bit pattern you know whether left, right, middle or any combination of buttons is pressed at that moment.
On a Mac, its ‘the button’ and thats the end of it.
I could subclass the window and grab the WM_MOUSExxx messages (which is how I solved something like this in 2009) , but its crackers that I need to do that for such a basic requirement.
My workaround will work in most cases, so it’s not worth making too much fuss.
Just a little disappointing that this is still not available after all this time, especially since Xojo must surely be getting these messages to handle the keyboard.async functionality…
WM_MOUSEMOVE wParam contents:
MK_CONTROL 0x0008 The CTRL key is down.
MK_LBUTTON 0x0001 The left mouse button is down.
MK_MBUTTON 0x0010 The middle mouse button is down.
MK_RBUTTON 0x0002 The right mouse button is down.
MK_SHIFT 0x0004 The SHIFT key is down.
MK_XBUTTON1 0x0020 The first X button is down.
MK_XBUTTON2 0x0040 The second X button is down
[quote=248368:@Jeff Tullin]Indeed.
Digging around I find that I was logging queries about this on the old forum more than 7 years ago.
This is a case where the function is definitely Mac led.
On all other windows development tools I have used, mouse events supply a parameter that is a bitwise representation of the mouse button states.
By examining the bit pattern you know whether left, right, middle or any combination of buttons is pressed at that moment.
On a Mac, its ‘the button’ and thats the end of it.
I could subclass the window and grab the WM_MOUSExxx messages (which is how I solved something like this in 2009) , but its crackers that I need to do that for such a basic requirement.
My workaround will work in most cases, so it’s not worth making too much fuss.
Just a little disappointing that this is still not available after all this time, especially since Xojo must surely be getting these messages to handle the keyboard.async functionality…
WM_MOUSEMOVE wParam contents:
MK_CONTROL 0x0008 The CTRL key is down.
MK_LBUTTON 0x0001 The left mouse button is down.
MK_MBUTTON 0x0010 The middle mouse button is down.
MK_RBUTTON 0x0002 The right mouse button is down.
MK_SHIFT 0x0004 The SHIFT key is down.
MK_XBUTTON1 0x0020 The first X button is down.
MK_XBUTTON2 0x0040 The second X button is down[/quote]
The declare for MouseMove is in WS TreeViewWSF. It should not be too difficult to implement it completely.
Jeff,
I’ve also suffered from what you say:
[quote]This is a case where the function is definitely Mac led.
On all other windows development tools I have used, mouse events supply a parameter that is a bitwise representation of the mouse button states.
By examining the bit pattern you know whether left, right, middle or any combination of buttons is pressed at that moment.
On a Mac, its ‘the button’ and thats the end of it.[/quote]
I’m also a Windows developer, mainly in CAD and the possibility of using different mouse buttons (even the mid one) and their combination was something I was used to count on, and it’s clear that this is a toll I must pay if I want to use Xojo. It doesn’t seem that something is going to be done to facilitate Windows users what is “normal” in their world. We must adapt the way Apple works or fight with Declares as I did, but when 64bits arrived it was again a new fight; finally I surrendered.
To be fair, the most advanced Mac programmers use a lot of declares to overcome Xojo limitations, and have to suffer the same plight when systems change. And since Apple issues a new system every year, it can be quite an undertaking to keep current. Sam Rowlands, for instance, has regularly reported new “surprises” in each recent versions of Mac OSX.
At least, on Windows, we can count on WinAPI stability. Sure, the advent of 64 bit means making sure call parameters are compatible. Mostly Int32 instead of Integer.
Michel,
You’re right, but…
When I checked my main application with 64 bits, I had many problems that were solved step by step. However there is one I haven’t been able to solve:
I use the mouse middle button to PAN (move) the image on the screen, since it is very common in CAD world (AutoCad, for example). I lost some hours and I got no positive result. Now I’m waiting for the 64 bits debugger to start my fight again.
But as Jeff says:[quote=248368:@Jeff Tullin]I could subclass the window and grab the WM_MOUSExxx messages (which is how I solved something like this in 2009) , but its crackers that I need to do that for such a basic requirement.[/quote]
I know that there is a problem with Integers and int32 but also with pointers and declares. I use SetWindowLong and as you can see in https://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx there are new functions for 64 bits, which, according to some Internet forums, give some problems.
Conclusion: It’s a pity that managing mouse buttons is not as easy as it used to be those days with VB6.
I remember clearly a discussion about your need for the third button.
From what I see at
https://msdn.microsoft.com/en-us/library/windows/desktop/ms644898(v=vs.85).aspx
and
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633591(v=vs.85).aspx
the call parameters are strictly identical. At first glance it should be fairly straightforward.
I think you may want to tune the declare with SetWindowLongPtr under 32 bit first, and chances are it will work right away in 64 bit, if you make sure to use the proper parameter for nIndex which I believe should be Int32 instead of Integer, since in 64 bit, Integer becomes int64.
Michel,
Thanks for your attention. The problem is I’m not a software engineer but an architect programming technical software. And many times this lack of knowledge represents hours trying to solve stupid problems that for some of you are very straight. And trying to understand the difference between SetWindowLong, SetWindowLongA, SetWindowLongPtr and why it doesn’t work when I substitute them because LONG changes to LONG_PTR, etc. etc. is an example of this type of losing time for something that could be a normal feature of Xojo.
At this very moment I’m trying to solve this SetWindowLongA v. SetWindowLongPtr subject. I’ll tell you if I can solve it.
Thats not a middle button thing though, is it?
What are you trying to set?
You should probably call SetWindowLongPtr
LONG_PTR WINAPI SetWindowLongPtr(
In HWND hWnd, //hwnd should be a window handle and 32 or 64 bit based on your compile
In int nIndex, // use Integer … this mutates between 32 and 64 bit too
In LONG_PTR dwNewLong // this is a pointer, defined as typedef __int3264 LONG_PTR;
);
Hi Jeff,
First of all thanks for your interest.
Here there is a link to a test project I’m working on: https://dl.dropboxusercontent.com/u/6172411/MidButton.xojo_binary_project
In 32 bits it works. You can drag middle button and move the TextField control.
But up to now I couldn’t do the same with 64 bits.
I’ll continue, but I think it would be easier to wait for 64 bits debugger.
I’ll download and have a look in a day or so… I dont own a 3 button mouse, so it would be debug statements at dawn…
(Poor Dawn, always gets it in the neck…)
[quote=248598:@Jeff Tullin]I’ll download and have a look in a day or so… I dont own a 3 button mouse, so it would be debug statements at dawn…
(Poor Dawn, always gets it in the neck…)[/quote]
On Windows when you press down on the wheel this is the third button.
Thanks Michel. I think I have a wheely mouse somewhere…