I'm trying to make my own custom text editor for my program, which so far does syntax highlighting. It can't even edit text yet.
I've run into a snag when trying to display my caret.
In my OnRender() method, I use IsKeyboardFocused to check to see if I have keyboard focus, which if I do, then it goes ahead and draws my cursor.
I have told the keyboard via Keyboard.Focus(MyCustomTextEditor) to focus on my control when I click on it with my mouse, and when I intercept it using a GotKeyboardFocus event handler, I can verify using debugging messages that the focus was passed successfully.
However, no matter what I do, I can't seem to make IsKeyboardFocused = True inside OnRender(). I placed Debug.Print()'s at the beginning, end, middle, and every other place imaginable inside OnRender(), with the results always being False.
My method seems pretty straightforward. I just don't understand what I could have left out. Thanks for your time reading this!
Have you tried using FocusManager.FocusedElement to figure out what element is focused when you're expecting your control to have focus? That should give a few clues.
Shot in the dark, is OnRender() being called again after control load, or are you only checking on init? I recall focus issues involving setting focus on a control during the Loaded event, only to have focus revert afterwards.
Related
From a production application, we notice that our WPF buttons fire the ICommand.Execute method twice on fast double click.
Now, on every Command, the application is covered with a full-screen spinner animation, preventing any further interaction with the application.
This github repo contains a minimalistic repro of the issue. Note that:
when the Button's Command fires, the "IsBusy" flag is set to true
as a consequence, the BusyIndicator overlay will be shown
as a consequence, the Button cannot be pressed again until after 300ms
However, especially on slow computers, when fast double-clicking (really fast, like gaming fast that is), it is possible to fire the command twice without the BusyIndicator blocking the second call (this can be seen if the output shows 2 'click' lines right after one another).
This is unexpected behavior to me, as the IsBusy flag is set to true right away on the UI thread.
How come a second click is able to pass through?
I would expect the IsBusy Binding to show the overlay on the UI thread, blocking any further interaction?
The github sample also contains 2 workarounds:
using the ICommand.CanExecute to block the Execute handler
using the PreviewMouseDown to prevent double clicks
I'm trying to understand what the issue is.
What work-around would you prefer?
Diagnosis
This is only my guess and not a solid and confirmed info, but it seems that when you click the mouse button, the hit-testing is done immediately, but all the mouse related events are only scheduled to be raised (using the Dispatcher I presume). The important thing is that the control that is clicked is determined at the time the click occurred, and not after the previous click has been completely handled (including all UI changes that potentially follow).
So in your case, even if the first click results in showing the BusyIndicator covering (and thus blocking) the Button, if you manage to click for the second time before the BusyIndicator is actually shown (and that does not happen immediately), the click event on the Button will be scheduled to be raised (which will happen after the BusyIndicator is shown), causing the command to be executed again even though at that point the BusyIndicator will possibly be blocking the Button.
Solution
If your goal is to prevent command execution while the previous one is still executing the obvious choice is to make the Command.CanExecute result depend on the state of the IsBusy flag. Moreover, I wouldn't even call it a workaround, but a proper design.
What you're facing here is a clear-cut example of why you shouldn't make your business logic rely on UI. Firstly, because rendering strongly depends on the machine's processing power, and secondly because covering a button with another control by far does not guarantee the button cannot be "clicked" (using for example UI Automation framework).
I have implemented a custom Undo/Redo stack and Im trying to get it to work with the WPF TextBox.
I have turned off the built in Undo-mechanism and hooked up my custom Undo on Ctrl+Z. Everything works fine accept that the caret in the TextBox is always being moved to index 0 on every undo/redo. The question is how to solve this?
I have tried having a custom behaviour on the TextBox which listens to TextChanged and is localizing the last change in the text-string. But this only works unless you start typing the same letter several times in a row. The my method breaks down.
What I ideally want is some kind of behaviour that only makes actual changes to the TextBox.Text-property. As it is now it is updated completely for every Undo, even if its only the last entered letter that is removed. This is of course no suprise since it listens to the Text-property on my PresentationModel which is triggering PropertyChanged on Undo.
But wouldnt it be great if there was some more fine-detailed way of telling exactly what had changed with the property-value, that only one or a couple of letters where inserted/removed in the string value. Then the TextBox could change only that without having to refresh its entire Text-value. Is there any such way of telling the TextBox this allready or could it be possible to make a custom TextBox that behaved in this way? Then it would be possible to pinpoint the exact location for the new caret without having it go straight back to 0 for every propertychange-update!
have a TextBox item (MyTextBox) on a TabItem control. I have code that looks as follows:
MyTextBox.Focus();
Keyboard.Focus(MyTextBox);
When I run this code through the debugger I see the following after the lines are executed:
MyTextBox.IsFocused = true
MyTextBox.IsKeyboardFocused = false
Can anyone tell me why the textbox isn't receiving keyboard focus? It's just a standard TextBox control that is enabled.
When you try to set Focus to an element besides the things enumerated above by our coleague, you must also know that WPF does not allow cross threaded operations.
In some cases this exception is not raised like in the Focus method call case. What I've done to fix this issue is to call all the code that involves Keyboards focus in an action.
This action is ran inside the control dispatcher to make sure that my code is not being executed from another thread than the UI thread (e.g. timer event or an event raised from another thread):
[UIElement].Dispatcher.BeginInvoke(
new Action(
delegate{
/// put your Focus code here
}
)
);
MyTextBox.IsKeyboardFocused is false because you are looking at it under debugger and the keyboard focus is probably in your Visual Studio... Try debugging focus without breakpoints (e.g. Debug.Write or trace brakepoints) to see actual values of MyTextBox.IsKeyboardFocused in runtime.
Also notice that Focus() method returns boolean value that indicates whether focus was successfully set. Does it return False in your case? If yes, I would suggest stepping into Focus() method in order to find out what is wrong.
3 important properties must be true: IsVisible="True", Focusable="True". IsEnabled="True".
To be focusable, Focusable and IsEnabled must both be true.
http://msdn.microsoft.com/en-us/library/system.windows.uielement.focus.aspx
The accepted answer here does not solve the problem of textboxes who dont gain focus, no matter what the debugger tells you. If you have and can write to your textbox, then you have it keyboard-focused.
I found this here solving the problem (and actually gaining focus, not just settings the values so it looks like focus in the debugger), it comes very close to Pavlov's answer but with the "Focus code" : Keyboard.Focus does not work on text box in WPF
This worked for me (had to do UpdateLayout, otherwise Focus() didn't work immediately after changing tab from script)
tabControl.SelectedIndex = 2;
this.UpdateLayout();
txtMyTextBox.Focus();
It's important where your first two lines of code are executed.
If they are in an event handler that relates to the user pressing a key, using the mouse, altering the visibility of a control, or otherwise taking an action that might have an impact on focus, I find manually calling Focus() often doesn't work.
My theory is that internally, WPF operates as follows:
User or code takes action which could have an impact on focus, e.g. a TextBox control becomes enabled inside a focus scope which previously had no focusable control.
WPF notifies various event handlers, including yours which calls Focus().
WPF updates focus based on the state changes in step 1. This overrides whatever you did in step 2.
That is why this answer suggests to call your Focus() in a queued callback which will be executed after step 3.
Side note: you don't need to call both UIElement.Focus and Keyboard.Focus since the first includes the second (at least if you trust the Microsoft docs).
In conclusion, replace your first two lines of code with this:
// using System.Windows.Threading;
Dispatcher.BeginInvoke(DispatcherPriority.Input, MyTextBox.Focus);
Well, in our application this usually works fine. But at some point, none of the CanExecute methods fire (even if I explicitly call CommandManager.InvalidateRequerySuggested(), the CanExecute methods don't run). Anyway, despite the fact that they don't run, they all get set to false, so every button, menu item, etc, bound to a CommandBinding, gets disabled until I click the MainWindow.
Now, I suspect another Window causing this, when we do a certain action, a Window pops up, and then after the next action, all the buttons become disabled, without going through the CanExecute method.
Has anyone seen such a behavior? Any suggestion on how to solve this, is greatly appreciated.
Thanks.
Fixed it. It was related to the other window I mentioned, but it wasn't exactly that. The problem was that we had a method to hide the mentioned window, in that method, we gave focus back to the main window, and THAT was the problem. Not sure how or why, but removing the
App.MainWindow.Focus()
Line fixed this problem. So, whenever you close or hide a child window, do not call the Focus() method on your Main one.
Thanks!
We have a 3rd party control loaded in our C# WinForms app.
When we call a method on this 3rd party ActiveX control, it asynchronously steals focus. For example:
// This call causes 3rd party to spawn a thread and steal focus
// milliseconds later.
foo3rdParty.DoSomething();
Is there a way to prevent a control from stealing focus?
If the control has a GotFocus() event (and it's correctly raised by the control whenever it steals the focus), you could attach a handler to that and set the focus back to the last control that had the focus (or the OK button or whatever).
This might produce weirdness if someone is typing in a textbox in the middle of this. My solution would be to give my money to someone who was willing to do maybe 15 minutes of work to help me.
If this evil little control isn't meant to be visible, you could place it on an invisible form and call DoSomething() on it there. Then, who cares if it grabs the focus?
ugh. you've probably already thought of this but can you disable the control's window during the period (or a guesstimation) when it tries to take focus, without hurting the user experience?
You could try this rough approach:
Find which control has focus before you make the call, say using Form.ActiveControl.
Attach a handler to the active control which gets called when it loses focus.
Make the call to the third-party control's method.
If all goes as expected, the third-party control will gain focus, and the previously focused control will lose focus, and the handler will be called.
In that handler, either set focus back to the previous control, or schedule some code to run on a thread to do so a little later.