I have a TextBox and a Button. When the button is clicked, the TextBox loses focus and the keyboard hides. How do I keep the keyboard from hiding when the button is clicked?
I first thought to use AllowFocusOnInteraction, but this is not supported on Android at this time.
Although AllowFocusOnInteraction isn't implemented, Control.IsTabStop is. IsTabStop likewise prevents the control from receiving focus. Use IsTabStop instead.
Uno Platform is using the Android input behavior here, so when the input loses focus, the programmatic keyboard automatically disappears. However, if you want to show it again immediately, you can give it focus again from within the button Click handler.
XAML:
<TextBox x:Name="InputBox" />
<Button Click="TestClick">Test</Button>
C#:
private void TestClick(object sender, RoutedEventArgs e)
{
InputBox.Focus(FocusState.Programmatic);
}
The input pane starts disappearing, but is immediately requested again, so it is almost imperceptible.
You can also try to trigger the soft keyboard programmatically without having any TextBox in place, by writing platform-specific code. This SO question for example includes quite a few solutions for Android. In general, they utilize the INPUT_METHOD_SERVICE and call ShowSoftInput on it.
Related
I have a Xamarin.Forms (3.4) app with several Content pages, some of which have several entry boxes. If go to a page, then edit an entry, so far everything is fine. But when I "exit" the page (by doing a Navigation.PopModalAsync() ), and then return to the page, on iOS there is immediately a cursor in the entry, and also the keyboard pops-up. This is not what my user will expect.
On Android, the cursor is in the entry, but it does not pop up the keyboard automatically. This too is not desireable.
For refernce, on UWP it doesn't show focus when returning to the page.
How can I avoid this behavior? Is there a way to have the page "clear" the focus?
You should do something like:
override protected void OnAppearing()
{
entry.Unfocus();
}
I have a Qt form, where I have a button and menu. For various reasons I can disable certain elements, e.g button or some actions in the menu.
Is there a way I could show a tooltip or when the mouse is hovered over the disabled button or menu item with an explanation as to why it is disabled?
I am using Qt 4.8.
Thanks!
You can set the tooltip dynamically based on the state of the QWidget or by simply toggling both at the same time. Upon disabling/enabling the widget from somewhere just call QWidget::setToolTip(...) with the QString you want the tooltip to display when hovering with the mouse over the given widget. For example if you have a public slot called toggleButton(bool toggleFlag) which toggles the enable-setting of a button you can do:
void MyWidget::toggleButton(bool toggleFlag) {
this->ui->myButton->setEnabled(toggleFlag);
this->ui->myButton->setToolTip(toggleFlag ? QString("Enabled wohoo!") : QString("Disabled because I like it"));
}
You can of course do also change the tooltip by calling QWidget::isEnabled() and act upon its return value. Since you haven't given any code I can only assume how you toggle your button(s) so that's all I can give you for now.
UPDATE: It was pointed in the comments that tooltips don't work with disabled widgets due not receiving mouse events. Both statements are not true (note that I have used the same tooltip message since due to lack of minimal working example I didn't want to write a whole new project from scratch and used an existing one of mine instead):
Hovering a disabled button triggers the tooltip
Hovering an enabled button triggers the tooltip
I have a task that are hiding a dialog but I need to click the button belong to this dialog to
implement some function before go to the next dialog.
But when I hide this dialog, I can't click the button. Is there any way to implement this button without On_Bn_Clicked() event? I mean that when the dialog is called, the button is also activated.
Thank for the helps.
When you click the button a few Windows messages are sent. The important ones are WM_LBUTTONDOWN, WM_LBUTTONUP which tells the button you clicked the left mouse button down and up. Then some time later a WM_COMMAND message is sent to the parent window to handle the button click. At that point your ON_COMMAND() MFC handler is called. MFC abstracts this all away from you for the most part.
You could go and simulate this using the Win32 SendMessage API but if the message pump is blocking your button may not be clicked when you think it will. If you want a quick answer to your question then this is an approach to "get it done". It would look something like this:
SendMessage(button.GetSafeHwnd(), WM_LBUTTONDOWN, MK_LBUTTON, 0);
SendMessage(button.GetSafeHwnd(), WM_LBUTTONUP, MK_LBUTTON, 0);
I think a more sensible approach is to take the code that is in this On_Bn_Clicked() event handler and simply move it to a reusable function. This way you can call the code in On_Bn_Clicked() from anywhere in your program.
Just call On_Bn_Clicked() directly from your code. There is no harm in doing so. (I suppose you don't want to actually click the hidden button with the mouse...)
In GUI dialogs, most applications provide for keyboard control as follows:
Enter key - presses the default button. (Default is usually indicated with a bold button border.)
Esc key - presses the Cancel or close button.
Space key - presses widget that currently has keyboard focus.
Tab key - advances focus to next widget.
Question is, when keyboard focus is on a widget that is a button, should the default button be changed to be the one with focus?
I see some issues with this behavior:
The display noise of redrawing buttons to unbold the outline of original default button and rebold the button under focus as being new default.
The Space key is now somewhat redundant with Enter key.
There is no keyboard accelerator to get the normal default button now (Usually the OK button).
However, it seems the trend has been in this direction to change the default button with focus change to another button. What is the rationale for this departure from the early GUIs? It would seem to provide less functionality given there is no way to press the original default button. Did people find that the original model was too complicated for users to understand? I would think keyboard control of dialogs would be a task for advanced users who would have no trouble understanding the model and prefer to have accelerator for current button (Space) and original default button (Enter) at all times.
Note that Qt for one is supporting the change: QPushButton's autoDefault property is responsible for the behavior of changing the default button. By default its value is true. Therefore, you must take extra action to set it to false for all buttons, to prevent them from becoming the default button when focused.
This is not a "departure from the early GUIs", at least not if by "early GUIs", you mean Windows 1.0. The behavior that you describe has been this way since the beginning.
The focused button is always "pushed" when the Enter key is pressed. The default button is only triggered in the following two situations:
The default button has the focus (which it does by default), or
The focus is on a control that does not process Enter key presses (such as a static control, or a single-line textbox that does not have the ES_WANTRETURN style flag set).
The famous Win32 blogger Raymond Chen has a post explaining this behavior (focus specifically on the last two quoted paragraphs):
A dialog box maintains the concept of a "default button" (which is always a pushbutton). The default button is typically drawn with a distinctive look (a heavy outline or a different color) and indicates what action the dialog box will take when you hit Enter. Note that this is not the same as the control that has the focus.
For example, open the Run dialog from the Start menu. Observe that the OK button is the default button; it has a different look from the other buttons. But focus is on the edit control. Your typing goes to the edit control, until you hit Enter; the Enter activates the default button, which is OK.
As you tab through the dialog, observe what happens to the default button. When the dialog box moves focus to a pushbutton, that pushbutton becomes the new default button. But when the dialog box moves focus to something that isn't a pushbutton at all, the OK button resumes its position as the default button.
The dialog manager remebers which control was the default button when the dialog was initially created, and when it moves focus to something that isn't a button, it restores that original button as the default button.
The behavior that I would expect is:
If I press enter when the window just pop up, it should press the default button
If I press tab, I start navigating through the widgets. In this case there are two options:
2.1 I press enter - this event should be delivered to the focused widget. There's no need to change the default button - simply hand the event to the focused widget.
2.2 I press escape. In this case, everything should go back to the state after the window is created.
Notes:
I come from a mixed background - I don't know if I learned this in windows, linux or Mobile OSes! This is just how I expect things to work out.
I don't use the space key (didn't know it's functionality)
I render Qt gui elements on my own 3d application screen by rendering Qt stuff to QImage and then drawing that on the screen. I redirect input to QGraphicsScene, but not everything works. Clicking buttons works fine while clicking QLineEdit or web page elements in QWebView doesnt. However doubleclick seems to work - doubleclicked QLineEdit would select some text, but still would not gain focus. What could be causing this?
I had the exact same problem. It seemed i had
QGraphicsView.keyPressEvent(self, keyEvent)
implemented in my graphicsView. Had to resend the event up the chain of inheritance.
I also implemented keyboard event sending. No matter how i send events (QGraphicsScene::keyPressEvent()/QGraphicsScene::keyReleaseEvent() or QApplication::sendEvent) text is not typed into control, even if some text is selected in QLineEdit (text should be overwritten, shouldnt it?). I suspect this is because of QLineEdit not gaining focus by clicking it, but i cant find out why it is not focused. All events are sent to my subclass of QGraphicsScene.