I have an app that has a canvas with a contextual menu. I also use the mousedown event and return true. On Windows the contextual menu shows, on OSX Cocoa it will only show if I return false to the mouse down event.
Is this expected? Is there a workaround?
Not sure how you have done it but have a look in example projects/desktop/menus/CostructContextualMenu
Add the event mousedown and return true it still shows the menu.
In a very simple project I just have a canvas on the only window. In the constructcontextualmenu event I have
base.append New MenuItem(“Delete”)
Return True
In the ContextualMenuAction Event I have
Return True
At this point it works. When I right click on the canvas the menu is shown.
If I then add the MouseDown event with just
Return True
Right clicking the canvas no longer shows the menu. Setting a break point in the constructcontextualmenu doesn’t get hit.
All this works on Windows without a problem. I even found my genuine apple mouse just to remove the Logitech one I usually use and the problem is still there.
Right figured it out. By returning true in mousedown no further event handling is done so I guess constructcontextualmenu is not firing. Therefore if you can live with not returning true if it was a right click but returning true if it was a left click, the following should get you out the woods:
Put this in your mousedown event to replace where you have Return True
if IsContextualClick then
Return False
else
Return True
end If
Thanks Mike, works a treat. I still think the behavior should be the same for Windows & OSX though.
I’ve not used windows in a long time but doesn’t the contextual menu trigger on mouse up in windows?
I guess it does seeing as I don’t need to check for iscontextualclick in the mousedown event on Windows.
I don’t think it is a bug is it? Can someone sitting at a windows machine now confirm that contextual menus appear on mouse up not mousedown. And I can verify on mac they appear on mousedown and not mouse up. Hence the fix I gave Wayne above. Or am I wrong?
On Windows 7, Xojo 2013r3.3, the code is in the MouseDown but the menu does not appear until the mouse button is released. No code is needed in the MouseUp event.
So I don’t think this is a bug then. Just windows users expect context menus on mouse up and mac on mouse down.
However if you return false in mouse down I wouldn’t expect the context menu to appear on windows is that the case?
That’s correct. It is usually best to test for IsContextualClick at the start of the mouseDown event to distinguish between the left and right button.
So… In summary the feedback cases are not a bug but a misunderstood feature of the operating systems. I will post the above fix/comments on Xippets so it is known for future reference
I disagree that it’s not a bug. At the very least, there’s missing documentation about the platform differences. Remember, one of the things Xojo is supposed to do for us is (when feasible) to smooth out the cross-platform differences so we don’t have to write quite so many #if TargetXXX special cases.
See also the recent discussion about mouse scroll behavior as well - the consensus seems to be have the framework adopt the Mac-style behavior even though Windows-style is different.
Michael, I strongly disagree with the implications of your last statement. If I write code to be cross platform, I want it to operate as is normal on the specific target platform. I don’t want Windows apps to operate as if they were on a Mac, or vice versa.
I am well versatile on both platforms but my customers may not be. And I shouldn’t have to special-case my code to have the appearance of a Windows app on Windows.
For myself, I have used so many good, not-so-good, and simply terrible IDEs over the years that I can be happy if the thing works (remember the early versions of MPW?). But the resultant code should not have the end user puzzling why the Windows app doesn’t look or feel like a typical Windows app.
I think you have this backwards. The consensus seems to be that Xojo was wrong about what the Windows-style is.
Windows style for mouse over & scroll behavior is that it does NOT in general do this.
OS X does.
A good example is that Windows Explorer does not scroll without putting focus on an item in the list.
Some apps override that behavior (firefox & chrome do)
The poll was roughly “Should Xojo override that behavior and scroll things when the mouse is over them, like on OS X, rather than when they have focus”
I’m a Windows-only user and I can’t think of a single program I use, other than IE (and I don’t use that), that works that way. Even Windows Explorer scrolls the pane under the cursor, not the one that you last clicked on.
I see MS current recommendations recommends it work this way now but I don’t think thats always been the case. It certainly is’t present in all places. The file open dialogs don’t do it which is what annoys the heck out of me when I’m working in the IDE trying to debug some problem.
There’s lots of articles about this NOT being the default & people wanting to know how to make it be that way like this one http://gigaom.com/2009/02/12/scroll-in-windows-without-the-cursor-focus/)
About 2/3 of the way down the page they do say
Mouse wheel
Make the mouse wheel affect the control, pane, or window that the pointer is currently over. Doing so avoids unintended results.
Make the mouse wheel take effect without clicking or having input focus. Hovering is sufficient.
So I’d say the survey & the MS article just confirms it SHOULD work like OS X which makes more sense to me anyways 