Hi,
I'm using SmartClient Version: v8.3p_2014-03-06/PowerEdition Deployment (built 2014-03-06) (SmartGWT 3.1p) with PostgreSQL 9.2.2, Firefox 26 and Tomcat 7.0.33.
I'm using includeFrom to reference some values in look up tables. Things are working pretty well, but I've encountered an odd error condition.
I am using both a filterEditor and a filterBuilder. On the DataSourceField I use setEditorType to set the optionDataSource, valueField and displayField so that the pick list in the filterBuilder for the field will show the list of available choices.
I'm having a problem with the filter builder. One of other fields in the dataSource is a date-time field. When you add a clause to the filter builder you can pick the data-time field from the list. This provides a default value of 'today' for the date-time field. Then I can, in that clause, change the selected field from the date-time field to the includeFrom field. The system attempts to populate the pick list for the includeFrom field, but it uses the value from the date-time field as criteria. So I get an postgres error that says:
ERROR: invalid input syntax for integer: "2014-05-08 00:00:00"
I get this error because it is using the date-time field's value of 'today' as criteria for the includeFrom field which is based on an integer id referencing a look up table to get a matching string. The date string representing 'today' is not a valid value for the integer id. Even if it was an integer, it shouldn't be used.
It looks like filter builder is using the previous value when the column of interest is changed to the includeFrom field. The documentation implied that it would not do this, but it does. I have also tried to explicitly tell it to not use the previous value by calling FilterBuilder.setRetainValuesAcrossFields with false, but the behavior didn't change.
In the filter builder, when I switch to the includeFrom field, it should not use the previous field's value for the includeFrom field. Is there something I need to set that I missed or is this a bug?
Thanks,
Kevin
I'm using SmartClient Version: v8.3p_2014-03-06/PowerEdition Deployment (built 2014-03-06) (SmartGWT 3.1p) with PostgreSQL 9.2.2, Firefox 26 and Tomcat 7.0.33.
I'm using includeFrom to reference some values in look up tables. Things are working pretty well, but I've encountered an odd error condition.
I am using both a filterEditor and a filterBuilder. On the DataSourceField I use setEditorType to set the optionDataSource, valueField and displayField so that the pick list in the filterBuilder for the field will show the list of available choices.
I'm having a problem with the filter builder. One of other fields in the dataSource is a date-time field. When you add a clause to the filter builder you can pick the data-time field from the list. This provides a default value of 'today' for the date-time field. Then I can, in that clause, change the selected field from the date-time field to the includeFrom field. The system attempts to populate the pick list for the includeFrom field, but it uses the value from the date-time field as criteria. So I get an postgres error that says:
ERROR: invalid input syntax for integer: "2014-05-08 00:00:00"
I get this error because it is using the date-time field's value of 'today' as criteria for the includeFrom field which is based on an integer id referencing a look up table to get a matching string. The date string representing 'today' is not a valid value for the integer id. Even if it was an integer, it shouldn't be used.
It looks like filter builder is using the previous value when the column of interest is changed to the includeFrom field. The documentation implied that it would not do this, but it does. I have also tried to explicitly tell it to not use the previous value by calling FilterBuilder.setRetainValuesAcrossFields with false, but the behavior didn't change.
In the filter builder, when I switch to the includeFrom field, it should not use the previous field's value for the includeFrom field. Is there something I need to set that I missed or is this a bug?
Thanks,
Kevin
Comment