I am working on a wxPython app where I have a button with label text 'Allocate'. Additionally I also have 2 radio options on my app namely 'UnAllocated' and 'Allocated'. When the app launches by default the radio option 'UnAllocated' is selected and the button has label text as 'Allocate'. I have made event driven code to change the label text of the button from 'Allocate' to 'Re-Allocate' upon selecting the radio option 'Allocated'. Uptill now everything is fine and code works as intended.
Now the problem is in the event of radio option 'Allocated' the button label does gets a new label text as 'Re-Allocate' however it is overwriting the previous label text instead of changing. Then as soon as I bring my mouse cursor on the button the text gets refreshed and appears clean and clear. Below is my Code
def rdoAllocated_Click(self, event):
self.btn_Allocate.SetLabelText('Re-Allocate')
def rdoUnAllocated_Click(self, event):
self.btn_Allocate.SetLabelText('Allocate')
is there a way of refreshing the button label text automatically after the change to display clearly the new text instead of unreadable overwritten text.
Here is the image how it looks when getting updated
Try calling self.btn_Allocate.Refresh() This can happen sometimes, depending on platform and widget types. The Refresh simply tells the system to send a paint event in the near future, and will most-likely take care of the problem for you. If not then you may need to call the parent window's Refresh instead.
Related
I have a certain set of buttons registered so that they can be executed using letters in a keyboard or by mouse click. But I want to hide the text in the button from the user so that it looks more natural.
Heres part of the code:
ToggleButton btn1 = new ToggleButton("");
btn1.setMnemonicParsing(true); // instruction to parse mnemonic
btn1.setText("_7");
Now instead of the button showing a 7 in the middle I want it to be hidden but still function the same. I have a feeling it has something to do with the setVisible() method but I'm not sure how to use it for just the text inside the button instead of the entire button itself.
Most probably you can't do both at the same time. If you want to trigger the button using MneomonicParsing, then you have set the text and it will be visible in the button.
Why don't you use a onKeyPressed method of the container of those buttons instead? Then you don't have to set any text on the button. Like this:
container.setOnKeyPressed(k->{
switch(k.getCode()){
case NUMPAD7:
case DIGIT7: btn1.fire();
break;
//implement other cases
}
});
I'm new. I've determined I cannot make a label "active" and accept keyboard input, so I am trying text fields instead. Seeking advice as to how to kill off the built in keyboard when the user taps the text field, as I want to use my own keyboard (a series of images).
I can determine the active text field (textfield.editing == yes), but when I will kill of the keyboard it seems it also kills off the ability to enter any data into that text field.
Maybe I need to just "hide" the keyboard? Send it off the screen?
OK, I found a way to make this happen. I created some transparent buttons, and laid those over the top of the labels. When the button gets clicked, it designates the label below it should be the active label.
In a separate method, the users text runs thru a few conditions to determine which label (as designated by the transparent button) is active, and the text goes into that label.
I have a Qt application in which certain QLabel's display a tooltip if a certain internal condition occurs.
Since the tooltip has a timeout and is hidden by Qt automatically, the tooltip is kept alive by the application by showing the tooltip every 3 seconds (I did not find any mechanism to tell Qt to show a tooltip indefinitely).
The tooltip is displayed until the user clicks on the QLabel itself: the tooltip is not refreshed any more and disappears.
I now have a new requirement that the tooltip should also disappear if the user clicks on the tooltip itself. Is there a signal that is sent when the user clicks on a visible tooltip? Or is it necessary to use some more sophisticated technique?
EDIT
I have checked my code again, here is some extra information.
Qt does detect a mouse click on a tooltip and hides it, but the application immediately shows the tooltip again.
What I would like to do is that Qt informs my code of the mouse-clicked event, so that it stops showing the tooltip again and again. I have two possible solutions in mind, but I do not know if either of them is technically feasible:
Remove tooltip timeout: when a tooltip is shown, it remains visible as long as the user does not click on it. How can I display a tooltip without a timeout in Qt?
Keep the tooltip visible by repeatedly showing it; detect a mouse clicked on the tooltip in order to stop the keep-alive loop. How do I receive a signal when the user clicks on a tooltip?
Under the hood, the actual class that implements the tooltip is a private QLabel-derived class called QTipLabel:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/kernel/qtooltip.cpp#line119
There's nothing published in the interface to get at an instance of that class from QToolTip, so intercepting clicks would only be done with some sort of ill-advised hack.
That said: among the events that should "hideTipImmediately" is QEvent::mouseButtonPress...in fact, there's an event filter installed so that any click in the app will hide it:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/kernel/qtooltip.cpp#line325
So if you're not seeing the tooltip disappear when it's being clicked on, there's a bug. (Clicking on tooltips hides them for me in Qt-based apps under Kubuntu.)
Note the definition of QToolTip::showText:
void QToolTip::showText ( const QPoint & pos, const QString & text,
QWidget * w, const QRect & rect ) [static] Shows text as a tool tip,
with the global position pos as the point of interest. The tool tip
will be shown with a platform specific offset from this point of
interest.
If you specify a non-empty rect the tip will be hidden as soon as you
move your cursor out of this area.
The rect is in the coordinates of the widget you specify with w. If
the rect is not empty you must specify a widget. Otherwise this
argument can be 0 but it is used to determine the appropriate screen
on multi-head systems.
If text is empty the tool tip is hidden. If the text is the same as
the currently shown tooltip, the tip will not move. You can force
moving by first hiding the tip with an empty text, and then showing
the new tip at the new position.
Thus, you can supply the rectangle in which the QToolTip is to be presented. Then, if what you want to do is close the QToolTip only when the user clicks on it, you can capture mouseButtonPress events as #HostileFork pointed out and then close the tooltip only when the coordinates of the event fall within it.
I have a custom TextInput that listens for the FocusEvent.FOCUS_IN and FocusEvent.FOCUS_OUT events:
textDisplay.addEventListener(FocusEvent.FOCUS_IN, onFocusInHandler);
textDisplay.addEventListener(FocusEvent.FOCUS_OUT, onFocusOutHandler);
My onFocusInHandler function basically removes a "promptview" that tells the user to type in a value, with the onFocusOutHandler doing the opposite.
For example, if the TextInput text was backspaced to a blank value and the user clicks out of the TextInput box, it would show a "Please enter a value" light-gray prompt in the TextInput.
This works fine until the user clicks our custom "Clear" button. The clear button sets the text to "", and I can tell the FocusEvent.FOCUS_OUT is received because the prompt text is set to visible (its not being set anywhere else). The problem is, the cursor remains in the box as if it still has focus, so if the user immediately starts typing, both the prompt text "Please enter a value" and the user-entered text appears over the gray text, which looks pretty ugly and unreadable.
Why does the TextInput receive the FocusEvent.FOCUS_OUT event if it's not actually losing focus? Is there any way I can get around this?
Option 1. Use the Spak TextInput in Flex 4.1 or 4.5. This already provides a promptDisplay by default (as mentioned in the comments)
Option 2. Take a look at the focus-skin. This skin class is usually placed on top of the normal skin. There could exist some focus ambiguity between these two. Try using a custom focus-skin without a textDisplay and clear button.
Option 3. Not only use a focus event to show or hide the prompt, but also look at the content of the TextInput. You don't want to display a prompt when the text is set by binding as wel.
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)