Am I missing something obvious?
Please see sample project run and hit “ESC” on your keyboard:
https://drive.google.com/open?id=0B3QGw9mryKYPaWpUb0tVeEFhUlE
The cancel button is fired despite of returning true in the KeyDown event of the canvas.
How can I prevent this?
just have an ordinary button with Cancel as the caption?
No it should be the cancel button but in some cases (when my canvas has the focus) I want to prevent the cancel button to be fired.
I thought handling the KeyDown for myself would be enough but I think I have to check the focus of my canvas in the action event of the cancel button.
The question is if this is a bug or not?
Not sure.
But you can prevent a window closing using the CancelClose event, cant you?
[quote=342417:@Jeff Tullin]Not sure.
But you can prevent a window closing using the CancelClose event, cant you?[/quote]
Not in my case:
Why is this not an option???
A “cancel” button IS an ordinary button with “CANCEL” as the caption, but with a built-in event… …and event that you do not wish to occur… So why try and make it do something it isn’t made to do? The “Cancel” button is provided as a convience for when it is appropropriate, in this case it is not.
and in your previous post you contradict yourself.
[quote]Click on the cancel button → window should close[quote]
earlier you said
how about when you do not wish the cancel button to be used, simply disable it?
I don’t think its a bug per se more of a feature that needs to be programmed around.
ESC to close a window is pretty standard on macos and windows. If you dont want it to happen, uncheck the Cancel Boolean for the button and handle it in your own WIndow1.KeyDown event. This event will only fire is nothing else intercepts/handles the key stroke, for example, when your canvas doesn’t have focus.
Or, you could keep it as it is, and have a bool for focus tracking on your canvas, set the bool to true when your canvas has focus and false when it loses focus, then in your Cancel button, only perform an action when this bool is false (ie. when focus is not on the canvas).
Or, you could set PushButton1.Cancel = False in Canvas1.GotFocus and PushButton1.Cancel = True in Canvas1.LostFocus
Many way to get around this.
Just to add data: I’m not able to reproduce the described behavior on macOS 10.11.6 over here.
Hmmm, guess it is a Windows only bug then, I was just assuming it was the same on the Mac, thanks Tim.
The ESC to trigger a Cancel button is a thing on Mac though, so we should figure out the expected behavior and file a feedback case. I appreciate how if I’ve got a form on a sheet window with a Cancel button that even if a TextField has focus the Cancel button can still be fired. This is how it’s supposed to work for me, and I do not want this to change.
So, to me, the OP’s project is exhibiting a bug on macOS, since the Canvas is consuming the ESC/Cancel.
Example Proj: http://timi.me/.misc/expected_sheet_cancel_behavior.xojo_binary_project
Yup, I saw the same issue but I don’t use macos enough to know what is regarded as standard behaviour there. I just figured macos was right (as almost everything come from there first) and as it was different to Windows then it was windows that was “wrong”. if someone puts in the ticket, just make then aware its different on the two platforms and to come to some agreement between the two, whichever they fix is in the hands of the gods devs.
It would only be an option if I implemented the behaviour for myself in the Window.Keydown event (thanks @ for the hint).
No I don’t.
CLICK on the cancel button should close the window.
ESC should also close the window but only if my canvas doesn’t have the focus.
But nevermind … I know how to program around the issue.
The question is if this is a bug or not.
@ and @Tim Parnell thanks for your efforts.
I’ll check this on macOS too and file a bug report.
As @Tim Parnell said on macOS it is different.
The KeyDown event of the Canvas is handled and the cancel button does not fire.
In my oppinion this should be the right behaviour.
Unfortunately I’m not able to file bug reports at the moment regarding to this issue:
https://forum.xojo.com/42138-error-on-submitting-feedback-case
Does anyone else want to create a ticket meanwhile ;-)?