TextItem field Value Repopulates with previous value when retyped

[SubhabrataGhosh]

Hi,

I'm having a problem with TextItem field. I have upgraded smartgwt 3.1 to smartgwt 5.0 .
I have used CharacterCasing.Upper in TextItem for my client requirement. It was working fine in smartgwt 3.1 version but now in smartgwt 5.0 version, if I miss-type something in the Text field and hit backspace button to remove miss-types text (not full of text field value) then I can remove the text but when I re-type then the deleted text are populating again.

I have attached image regarding problem.

Please Help.

I'm running on

SmartClient Version: v10.0p_2015-03-14/PowerEdition Deployment (built 2015-03-14)
GWT 2.7.0
java 1.8 (64bit)
FireFox 25 and above, Chrome latest, IE 9

[Isomorphic]

The first thing to do is to upgrade to the latest nightly build of 5.0 from smartclient.com/builds - if you still see issues, let us know.

[SubhabrataGhosh]

Thanks for the upgradation, but the latest version still has some issues. This worked fine in earlier version (smartgwt 3.1).

1. TextItem - When a value is typed and then it is removed and again a new letter is typed it holds the previous first letter.
Please refer to the attached detailed step by step screen shots.



2. SelectItem - When a value is keyed it gives a like search suggestion and then removing characters one by one changes the search which works fine, but when all the characters are removed then it holds the last character search suggestion, which is not correct it should show blank or no suggestion.
Please refer to the attached detailed step by step screen shots.









An update will be highly appreciated.

I'm running on

SmartClient Version: v10.0p_2015-10-27/PowerEdition Deployment (built 2015-10-27)
GWT 2.7.0
java 1.8 (64bit)
FireFox 25 and above, Chrome latest, IE 9

[Isomorphic]

We're definitely not reproducing the first problem. If that were really occurring, we would expect to be flooded with reports of the issue, so we strongly suspect something is wrong with your test environment.

On the second problem, that appears to be a ComboBoxItem, not a SelectItem. And, the normal behavior of the ComboBoxItem is to *close the picklist* if you clear the field, so here again, something appears to be special about your application.

Instead of screenshots, try putting together a minimal, ready-to-run test case that demonstrates the issues you're seeing.

[SubhabrataGhosh]

Hi Isomorphic,

I have upgraded smartGWT 5.0 nightly build (SmartClient Version: v10.0p_2015-10-27/PowerEdition Deployment (built 2015-10-27)) from smartGWT 3.1.
I faced some problem in TextItem field which was all right in smartGWT 3.1 version.

I have use CharacterCasting.UPPER in the TextItem.

Problem is:
1. I entered some value. eg: 'A'
2. I removed all input.
3. I type something again. eg: only 'S'
Then I got 'SA' in the textbox.

Problem only occurs if I use CharacterCasing, without CharacterCasing it behaves properly.

I'm attaching screen shot. Please look at scenario and help me.
Thanks in advance.

[Isomorphic]

As with the previous poster, we don't need a screenshot, we need code that reproduces the issue.

When you just post a screenshot of your app, we have no idea whether the problem is in your application code or in the framework.

And in both of the above claimed bugs, we already have tests that cover these use cases, so it's very likely an application problem, or unusual combinations of settings and overrides you're using that we could never guess.

Hence the need for a test case that reproduces the issue.

[SubhabrataGhosh]

Hi Isomorphic,

I Have a common place where created all TextItem.

TextItem TxtAsk = null;
TxtAsk= (TextItem) ComponentUtility.getFormItemInstance("txtAsk","","",100,"text",bill_print_scx.getBill_print_controller(),true);
TxtAsk.setHeight(40);
TxtAsk.setLength(40);
//TxtAsk.setShowFocused(true);
TxtAsk.setShowTitle(false);



and I called the method getFormItemInstance and created textItem. Below is the code:


FormItem formItem = null;
if(type.equals("text") || type.equals("textInCase")){
TextItem txtItem = new TextItem(id, title){

@Override
public void setVisible(Boolean visible) {
super.setVisible(visible);
//super.redraw();
}
@Override
public void setCharacterCasing(CharacterCasing characterCasing)
{
super.setCharacterCasing(characterCasing);
//super.redraw();
}

};

if(type.equals("text"))
{
txtItem.setCharacterCasing(CharacterCasing.UPPER);
}

formItem = txtItem;
formItem.setHeight(25);




Please help. Thanks in advance.

[Isomorphic]

A test case means runnable, standalone, minimal code. This is nowhere close to that, in fact the runnable portions of the code provide no more information than you already provided, which again, don't reproduce the issue.

See the FAQ and the Debugging overview if you need some further hints on how to build test cases.

[SubhabrataGhosh]

The code is running fine on IE but in Mozilla and chrome.

I think problem is on the isc_TextItem_handleKeyPress method in ISC_forms.js file.
can you please take a look.

[Isomorphic]

Please re-read previous responses. We do not investigate until we have a minimal, ready-to-run test case. We put this policy in place because we get a huge number of bogus bug reports.

[Isomorphic]

A quick follow up on this.
We have still never seen this problem in house, but we did recently fix an issue in this general area, so if you're still having problems here it might be worth re-testing with the latest nightly build (5.1p or 6.0d branches).

And to be clear, if this problem does persist for you even with this change, we'd unfortunately still need a way to reproduce it before we could give you any input.
We aren't seeing anything like this with standard tests of the characterCasing feature, so we'd really need to see a complete runnable test case to investigate. This would mean a small, self contained EntryPoint class which simply defined and drew enough UI components to reproduce the problem, and which we could run on our end without modification.

Regards
Isomorphic Software