2.5 SelectItem pick list width bug (standalone project included)

[sunnyl]

Hi all,

Recently upgraded to the SmartGWT 2.5 JAR and found that SelectItems which were previously working in 2.4 shows strange pick list width behaviour.

1) setPickListWidth is not set, so it should default to the width of the SelectItem as defined by the API
2) Everything works fine when viewing pick lists
3) View pick list with long text that is longer than the width of the SelectItem
4) Any pick list from that point onwards is the width of the pick list in 3)

I have:
1) Created a standalone project using 2.4 JAR - works fine
2) Dropped 2.5 final JAR in, clean, rebuild problem occurs
3) Dropped 2.5 nightly (2011-08-13) JAR in, clean, rebuild, same problem occurs
4) Reverted to 2.4 JAR, clean, rebuild, problem goes away.

This occurs in FF 5, and Chrome 13. Using GWT 2.2. Project attached (rename to zip). Drop gwt-servlet.jar and smartgwt.jar into WEB-INF/lib

	/**
	 * This is the entry point method.
	 */
	public void onModuleLoad() {
		
		LinkedHashMap<String, String> map1 = new LinkedHashMap<String, String>();
		map1.put("1", "a");
		map1.put("2", "bbbb");
		map1.put("3", "cc");
		map1.put("4", "dd");
		
		LinkedHashMap<String, String> map2 = new LinkedHashMap<String, String>();
		map2.put("1", "a");
		map2.put("2", "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb");
		map2.put("3", "cc");
		map2.put("4", "dd");
		
		SelectItem cmbTest1 = new SelectItem("test1", "Select 1");
		SelectItem cmbTest2 = new SelectItem("test2", "Select 2");
		SelectItem cmbTest3 = new SelectItem("test3", "Select 3");
		SelectItem cmbTest4 = new SelectItem("test4", "Select 4");
		
		cmbTest1.setValueMap(map1);
		cmbTest2.setValueMap(map2);
		cmbTest3.setValueMap(map1);
		cmbTest4.setValueMap(map2);
		
		cmbTest1.setWidth(150);
		cmbTest2.setWidth(150);
		cmbTest3.setWidth(150);
		cmbTest4.setWidth(150);
		cmbTest3.setWrapTitle(false);
		cmbTest4.setWrapTitle(false);
		
		DynamicForm form = new DynamicForm();
		form.setItems(cmbTest1, cmbTest2);
		form.setWidth100();
		
		ToolStrip ts = new ToolStrip();
		ts.addFormItem(cmbTest3);
		ts.addFormItem(cmbTest4);
		ts.setWidth("100%");
		
		VLayout rootWrapper = new VLayout();
		rootWrapper.setWidth100();
		rootWrapper.setHeight100();
		rootWrapper.setShowEdges(true);
		rootWrapper.addMember(ts);
		rootWrapper.addMember(form);
		rootWrapper.draw();
		
	}

I also have a more complex problem with 2.5 that involves DS drive SelectItems which I cannot reproduce in a standalone project easily due to the complexity of the code. Essentially the code uses Google's recommended MVP model, and switches between activities/views (represented by a TabSet). I found on one page which had a number of GwtRpcDataSource driven SelectItems that if I went to another tab and came back all the GwtRpcDataSource driven SelectItems would become blank. But if I click and show the pick list it seems to have remembered the previous selection, it just hasn't shown it for the display value. In 2.4 the SelectItems would retain their value and display value across tab selections. Sorry this is not extremely clear but as mentioned this would be a bit more involved to create in a standalone project - maybe there are some regressions in 2.5's SelectItem?

[Isomorphic]

The issue with the pickList failing to resize to fit the smaller values is something we've recently fixed.
The fix has been applied to the 2.5 branch, so will show up in nightly builds (under 2.5) going forward.

On the other issue, without a clearer picture of what's happening we can't really comment. We're not aware of a regression that would cause this behavior.
A standalone example would obviously be the best way to proceed and may be easier to achieve than you think. You can probably reproduce this by breaking out the simplest pieces into a new simple entryPoint class:
- copy a minimal set of the DataSource definitions involved, and consider reworking them to be client-only dataSources with test data. This will eliminate the need for any server-side code
- copy out the DynamicForm and SelectItem definitions for the forms that bind to these.
- from your description its not clear exactly what's happening when you're changing tabs in your application, but it should be possible to duplicate it with this simple set of DataSources and components in your test-case.

Apart from anything else, going though this process may make it clear exactly what is responsible for the bad behavior within your application, at which point we can determine whether a SmartGWT core behavior is broken or whether it's an application-level issue.