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