CheckBoxItem String value

[tgilbert]

Hi,

I seems that calling the setValue() method of a CheckBoxItem, with a string argument ("true" or "false") is not supported or not working. Can you please fix this ?

Here is a test case:

VLayout test = new VLayout();
	DynamicForm form = new DynamicForm();
	CheckboxItem item = new CheckboxItem("CB1", "First"), item2 = new CheckboxItem("CB2", "Second");
	item.setValue("true");
	item2.setValue("false");
	form.setItems(item, item2);
	test.setMembers(form);
	test.setWidth(500);
	test.setHeight(500);
	test.show();

In this example, both items are checked.

Regards,
Thomas

[bwilkins30]

CheckboxItem will not react to setValue until the form is rendered. You have to put it in some sort of call to FormActivate() or another area of your code after the form has been rendered.

[tgilbert]

Thanks, but I don't think so... If I replace "true" and "false" by their boolean equivalent, everything is working fine.

[bwilkins30]

Thanks, but I don't think so... If I replace "true" and "false" by their boolean equivalent, everything is working fine.

My apologies then.. seems to be just a local issue I had to work around. Best of luck.

[Isomorphic]

The value for a CheckboxItem is a boolean true or false value and not a String, so when you call setValue(), you do need to pass a boolean.

We don't plan to automatically adapt "true" and "false" values because it's not any more convenient, encourages wrong usage, and could interfere with things that subclasses may need to do (like allow a third state that is represented internally by a String).

[bwilkins30]

The value for a CheckboxItem is a boolean true or false value and not a String, so when you call setValue(), you do need to pass a boolean.

We don't plan to automatically adapt "true" and "false" values because it's not any more convenient, encourages wrong usage, and could interfere with things that subclasses may need to do (like allow a third state that is represented internally by a String).

Then why does the JavaDoc show it as an allowable method? I know it's because it derives from FormItem, but this should be prevented.

[Isomorphic]

Because a specialized subclass could still implement meaningful behavior for this method, as previously discussed.

[tgilbert]

Well, I do not agree... The item should adapt itself to the passed value, it really does not hurt to make it a little bit smarter. It's not a question of wrong usage here (in this basic test case, perhaps of course, not in our real situation).

[bwilkins30]

Well, I do not agree... The item should adapt itself to the passed value, it really does not hurt to make it a little bit smarter. It's not a question of wrong usage here (in this basic test case, perhaps of course, not in our real situation).

Thomas,

Can you subclass the CheckBoxItem and implement setValue yourself?

[bwilkins30]

Because a specialized subclass could still implement meaningful behavior for this method, as previously discussed.

I understand what you are saying, like a tri-state checkbox, but since you don't explicitly have a tri-state CheckBoxItem, having this method exist just because makes no sense. If someone wants to implement a custom setValue, like you imply, then they can do that without setValue(String) existing on CheckBoxItem. It's existence merely confuses people, as it has done here.

[Blama]

...but since you don't explicitly have a tri-state CheckBoxItem

Without further checking I think that the Checkboxes in a ListGrid's Filterrow for a boolean column are tri-state.

Best regards,
Blama

[bwilkins30]

Without further checking I think that the Checkboxes in a ListGrid's Filterrow for a boolean column are tri-state.

Best regards,
Blama

If I am not mistaken, those are auto-children.

[Isomorphic]

Whether your application is small or large, providing a String to a CheckBoxItem is incorrect usage. You simply need to correct your code, or as bwilkins suggests, add a setValue() implementation that correct the data type for you.

But we would really suggest fixing the underlying problem, because if the basic issue is that you have String values in a DataSourceField declared to be type:boolean, that's goes to cause problems in multiple components and subsystems. Boolean fields should have boolean values.