I have several TextField's inside a window along with a Button, e.g. aButton.
The TextField's, Button, and window all have setImmediate(True).
When a TextField loses focus some validation code is executed and if it fails it calls:
aButton.setEnabled(False);
When incorrect data is entered into one TextField and then focus is lost the debugger shows that aButton.setEnabled(False) is called but aButton still looks enabled.
Two possible things can happen from here:
1.) If one modifies data in another TextField and exits that field (loses focus), the validation can be successful or not for that field but the system knows to call aButton.setEnabled(False) as the previous TextField is still invalid. This time though aButton is visually disabled.
2.) If one clicks on aButton which is visually enabled it produces this warning then visually becomes disabled:
Warning: Ignoring variable change for disabled component < class 'ui.button.Button'>, caption=OK
Currently using Vaadin 6.7.3
Are there any known work arounds to force aButton to visually become disabled immediately (force the client to update) after manually setting it to be disabled?
Sadly I have only Vaadin 7 at my disposal right now, but I checked this anyway. It works as you wanted it to work and I have to jump to the conclusion that this should be the same in Vaadin 6.7.3. This part is not really different in Vaadin7... Have you tried this feature in an isolated code (only a textbox and the button)?
VerticalLayout vlTestContent = new VerticalLayout();
final Button butChangeMe = new Button("Enabled");
final TextField tf = new TextField("Blur", "default value");
tf.addBlurListener(new BlurListener() {
private static final long serialVersionUID = 5544993392287938660L;
#Override
public void blur(BlurEvent event) {
butChangeMe.setCaption("Disabled");
butChangeMe.setEnabled(false);
}
});
Button but = new Button("Change button", new ClickListener() {
private static final long serialVersionUID = -2235317499126190105L;
#Override
public void buttonClick(ClickEvent event) {
butChangeMe.setCaption("Enabled");
butChangeMe.setEnabled(true);
}
});
vlTestContent.addComponent(butChangeMe);
vlTestContent.addComponent(tf);
vlTestContent.addComponent(but);
(The second button is just for fun)
button.setVisible(false) will always work. You need to be careful to not fire up a another event on the focus lost event that ends up setting the visibility of the button to true.
You can request a repaint of a component or the whole window, but the whole point of the framework is that you will never need to do that, because visually modified components will automatically repaint on each request.
Just to be curious, do you let your request to finish before trying to see if the browser updates? Or you look at your browser right after you pass the setVisible() line in your debugger ?
I think that your point nr 2 happens because you clicked on the button, and what happens in this order is: 1st your focus lost event runs (which probably disables your button), 2nd button click runs and somehow a repaint is requested for that button because a state change happened in the button but a repaint show the warning that it won't do anything with it because it is disabled (was just disable by the focus lost event)
As a side note. I think this UI won't make for a good user experience, it should be the other way arround, if a validation is ok, then show the button (or better, always show the button, but enable/disable instead) But it depends...
Related
I have this code
setContent {
val items = mutableListOf<Int>().apply {
(1..100).forEach { add(it) }
}
LazyColumn {
items(items) { item ->
TextField("$item", {})
}
}
}
With android:windowSoftInputMode="adjustResize" in my AndroidManifest.xml.
If I click on a TextField at the top of the list, I can enter text fine.
If I click on a TextField near the bottom of the screen, the keyboard appears momentarily, then disappears quickly after, and prevents me from entering text.
How can I enter text when the TextField is at the bottom of the screen? Thanks!
Your keyboard disappears after having appeared for a brief, shiny moment. Here's the reason:
You tap the TextField, it calls it's built-in focus requestor, and requests the focus from the OS by calling appropriate (or inappropriate, who's to say) internal methods, as a result of which, the keyboard pops out (again, built-in mechanism.) and you can type all the more you want... AS LONG AS THE FIELD IS VISIBLE; or in Compose terms, long as the Composable holding the requestor, is in composition.
It should be clear, that once the Composable that owns the focus requestor goes off the screen, it is destroyed (well not every time, there are only certain specific cases when it is destroyed..., but yours is one of them), and when the Composable is destroyed, the focus requestor is destroyed. No focus requestor, no focus owner - the keyboard vanishes.
Now this is really important because you are using a LazyColumn, a lazy Composable, infamous for its merciless slaughtering of the Composables that are no longer visible to the user. HENCE, as long as it is the top (or other "visible") textfield that is in concern, it stays and works as expected. However, the bottom textfield, as the keyboard pops up, goes so much out of the visible bounds, that it gets slaughtered (recycled is the technical term, but what fun is that?), taking away the purpose of the keyboard.
Now, the lazy column, like any criminal, left a clue behind, and didn't notice it, which lead us to catch him red-handed. It is quite interesting, really, to see the column in action.
Now, workarounds include using a column, instead of a lazy column; creating your own lazy column using a custom lazy Composable, and manually handling the heap size for the Composable so the final field doesn't go out of composition.
That's it, you're cured.
Just leaving another answer, since OP didn't verify other purpose of him specifying adjustResize,if whether removing or changing it will be fine, but another solution aside from the mentioned comment about different API version is specifying adjustPan, which worked in my case, either
via AndroidManifest
android:windowSoftInputMode="adjustPan"
or programmatically
window.setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_ADJUST_PAN)
Same code base but with adjustPan
This issue is fixed in the current alpha version 1.4.0-alpha05
https://issuetracker.google.com/issues/179203700
I'm writing a small pyqt program. I want the main window to to react to arrow movement. I added an event to my MainGui class, keyPressEvent, that handle this. The event work fine as long as I don't press certain buttons such as Key_Up or Key_Down are directed to my (currently only) QComboBox and not to my mainGui. I tried to give the focus to mainGui after each paintEvent but then I need to double click on buttons/comboBox.
Then I tried to use the MousePressEvent to check if a certain element is under the mouse. This work fine with the comboBox, but not with the button.
So, how can I direct key events to the mainGui or give the focus to QButtons?
I used eventFilter to identify when the mouse enter the QPushButton and give it focus:
def eventFilter(self,source,event):
if event.type() == QtCore.QEvent.HoverMove:
if self.execButton.underMouse():
self.execButton.setFocus()
self.keepFocus=False
else :
self.keepFocus=True
keepFocus is a flag I initialized in the __init__ function of the class. I added this part at the paintEvent function
if self.keepFocus:
self.setFocus()
else:
self.keepFocus = True
Now, I keep the focus at the MainGui and I only give it to the button when the mouse hove over it. If I do another action (like pressing a mouse button or a keyboard key) the focus is given back to the MainGui. This will create some buggy filling (For example, I need to press twice a keyboard key before the first response) but this is workable.
I am currently working on a Customer Management application made in SmartGWT 2.0.
The Add Customer form is a fairly big one with multiple tabs and each tab has lot of fields. This form is opened in a modal window which have a save and a close button at the bottom.
Since this is a huge form, sometimes the rep accidentally hits Close without noticing that there is some information in one of the tabs.
We want to add some kind of alert when user tries to close the form after he has made changes to it.
I saw that there is ChangeHandler on text items which can flag a change which can be evaluated before firing the close event. However currently doing this for so many fields is a little bit cumbersome. Is there a way of achieving this on a DynamicForm level or even better on the Window level?
I am looking for a SmartGWT equivalent of this jquery code:
$("input:text, select, input:checkbox, input:radio, input:password").change(function(){
unloadRoutineFlag = true;
});
Take a closer look at this handler at the dynamicForm level.
addItemChangedHandler(ItemChangedHandler handler)
Handler fired when there is a changed() event fired on a FormItem
within this form.
Typically, when a formItem fires the changed() event, the form gets notified. Let us know if this works.
I am having a bit of a problem with an app I'm developing for BlackBerry.
I have a series of Item objects on the screen, each with a DefaultCommand tied to it. Example
below:
...
cmdBrowse = new Command(temp.id,Command.ITEM,0);
mainList.setDefaultCommand(cmdBrowse);
mainList.setItemCommandListener(icl);
...
Previously just clicking on the item with the confirm button would run the proper command. No problem there.
Then I added the handleKeyReleased method to capture the BlackBerry's back button as follows:
protected boolean handleKeyReleased(int keyCode, int gameAction) {
if(keyCode==1769472) {
/*code to deal with back button*/
return true;
} else {
return false;
}
}
Now when I click on the mainList Item with the confirm button, it brings up the list of commands first and I have to click again to actually run the command. Two clicks where it used to be one.
So, is there a way to either:
A. Keep the single click behaviour while still being able to capture the back button with handleKeyReleased
or
B. Capture the back button in a different way ?
I ended up overlooking one very simple thing. All I had to do was call the superclass's handleKeyReleased method and everything worked perfectly.
I am developing an app which supposed to work on devices that have OS 4.5 or later. In my application I need to know when the virtual keyboard is visible or invisible. Because if virtual keyboard is visible, the text area which the user is supposed to type in is behind the keyboard. If I could determine the moment of virtual keyboards state changed, I could refresh the screen and move the text area upper location.
Is there a way to do that?
Edit: the next button is at the status panel. The edit field is at the custom horizontal field manager.
When I touch the edit field, the virtual keyboard opens and the contents of the edit field is lost.
There is no way to do that with the same code. You need to divide your code in two. One of them handles 4.5 - 4.7. The other handles 4.7 and later.
You can add a keyboard listener to 4.7 (and later) code that should check whether the screen changes in a continuous thread. It is not good, but it can work.
You have two choices. The first choice is better:
Figure out an invariant that works with the keyboard visible or hidden. The screen layout method is invoked when the visibility state of the keyboard changes, and the vertical size is reduced for a visible keyboard. If your invariants take advantage of that then you can just implement the logic in the screen layout method.
In this case, I would suggest a layout method that always keeps the 'next' button at the bottom of the screen, and puts the username textbox in the center of the remaining space.
Use conditional compilation so you can write code that makes reference to the VirtualKeyboard class on OS 4.7+, and that code goes away in the older BlackBerry releases. 4 July: by conditional compilation, I mean use the BlackBerry preprocessor.
There is no event for this, but you can determine current state of virtual keyboard and set required state.
For example hide it
if(VirtualKeyboard.isSupported() == true){
VirtualKeyboard keyboard = getVirtualKeyboard();
if(keyboard != null)
keyboard.setVisibility(VirtualKeyboard.HIDE);
}
It is a quite challenging job. However, I believe there is no direct API or way to determine the virtual Keyboard state. The only way is to override the setLayout() method and determine if the screen width and height has been changed. And also you need to check the GUI layouts of your screen.
Set the VERTICAL_SCROLL style for the Manager which holds the EditField, or you can use a Screen with VERTICAL_SCROLL style. Doing this, the EditField automatically scrolls when the keyboard is displayed.
Use following class, maybe this is helpful for you:
class FocusableManager extends MainScreen implements FocusChangeListener
{
private BasicEditField b;
public FocusableManager()
{
VerticalFieldManager vfm=new VerticalFieldManager(VERTICAL_SCROLL);
vfm.add(new ButtonField("first"));
b=new BasicEditField();
b.setFocusListener(this);
vfm.add(b);
vfm.add(new ButtonField("second"));
vfm.setMargin(250,0,0,0);
add(vfm);
}
public void focusChanged(Field field, int eventType)
{
if(field==b)
{
if(eventType==1)//when edit field gain focus
{
VirtualKeyboard virtKbd;
virtKbd = getScreen().getVirtualKeyboard();
virtKbd.setVisibility(VirtualKeyboard.SHOW_FORCE);
}
else if(eventType==3)//when edit field lost focus
{
VirtualKeyboard virtKbd;
virtKbd = getScreen().getVirtualKeyboard();
virtKbd.setVisibility(VirtualKeyboard.HIDE_FORCE);
}
}
}
}