I have a DelayButton that I would like to stop flashing (after it's been pressed) when the operation triggered by the button is completed.
However, it appears that none of the properties DelayButton are writeable. Is there a way to stop the flashing, or must it always flash until the user presses the button again?
DelayButton is a subclass of the Button. The flashing state is actually linked to the checked property of the Button, so the button.checked = false will help.
You can always look into the source code: http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/src/extras/DelayButton.qml
Related
There are recipes on how to change focus on mouse move or client change.
But what I want, is to prevent any window from stealing focus. E.g. I open a new terminal via the default meta-Enter shortcut, and when it opens it immediately steals focus. Is there any way to prevent it?
Yes, it's possible. Focus events can happen in many ways. In the case of the new clients, just comment the focus line in your rules.
For the focus follow mouse, remove the client.focus = c in the mouse::enter section of rc.lua
For specific clients, you can add focus filters:
https://awesomewm.org/apidoc/libraries/awful.ewmh.html#add_activate_filter
For the deepest and most advanced focus control, you can disconnect the default focus handler (awful.ewmh.activate) from the request::activate (Awesome 4.0+) signal and implement your own. In that case, you will have absolute control over every focus events.
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 have a button named 'Start', and when it's clicked, a lengthy operation starts and I want it to change to a button named 'Stop'. The behavior when you click it obviously changes as well. What is the best way to implement this - by changing the button's text and reconnecting the 'clicked()' signal to a different slot, or by having two buttons and then hiding 'Start' and showing 'Stop'.
Both of your options work. A simple third alternative is to change the button text (changing the icon would be a good idea too), and saving the "state" (playing/not playing) somewhere. In your connected slot, just do the Right Thing depending on current state. (That way you don't have to reconnect anything).
Another option is to use the push button with setCheckable(true) set. This way the button acts more like a toggle-button (stays depressed when first clicked, raises back with second click), and combining that with your dynamic text/icon change.
If you use this, you should use the toggled(bool) signal rather than the clicked() one. The slot argument tells you whether the button is "active" or not. (This can also be queried with isChecked().)
I have a popup button that launches a canvas containing a form that a user can submit. I'm validating this form and displaying an alert when the validation fails. As soon as the user clicks 'OK' on the alert, the canvas launched from the PopUpButton loses focus and closes automatically (its default behavior). PopUpButton._closeOnActivity is private. Any suggestions are greatly appreciated.
Use PopUpManager and a normal button to pop something up manually instead of using a PopUpButton. You can then open and close it when you want to and avoid the default behavior.
var canvas:Canvas = new Canvas();
PopUpManager.addPopUp(canvas, this);
PopUpManager.centerPopUp(canvas);
PopUpManager.removePopUp(canvas);