I have a type-ahead field linked to a db-generated valuelist.
This field displays an address: if the city to which the address belongs is in the db, the address is taken from the valuelist, otherwise the address is inserted manually. Obviously, if the city is not in the db, the valuelist is empty. Everything worked ok until 3.5.3 but after installing 3.5.4 and 3.5.5, if the address is inserted manually, it is cancelled upon leaving the field and the value is not written to the database.
Reverting to 3.5.3 solves the issue. I suspect this is some sort of serious bug. Or now if there is a value-list attached to a field one must use the values of the list also if the list is empty? I hope not.
Servoy Developer (3.5.3,3.5.4,3.5.5)
Mac OS X 10.5.2
MySql 5.0.51a Intel
[fix] fields using valuelists with display and real values of different types will no longer accept other values than those in the display list
I am not sure if this refers to my problem: in my case display and real values are of the same type (text). The real value has just some more information (e.g. the street name, type of street, post code, etc) that are processed to fill the corresponding fields. If I correctly understand the change, this should not affect the behavior of the valuelist with reference to 3.5.3
if you pass an array with display AND an array with real values to the function application.setValueListItems(), it is not possible any more to type in a value which does not exist in the database.
In case you want allow values which do not exist in the database, you must not pass an array with real values (so display and real values have to be the same).
I have seen this behaviour in an intermediate build of 3.5.4. In the next intermediate build I used the problem was fixed. Sad to hear it reappeared in the final release…
f you pass an array with display AND an array with real values to the function application.setValueListItems(), it is not possible any more to type in a value which does not exist in the database. In case you want allow values which do not exist in the database, you must not pass an array with real values (so display and real values have to be the same).
In my method, in case there were no matching records for addresses, I passed two empty arrays to the valuelist and I could insert anything.
I just tried it in developer. What I would like to clarify is that this happens only in 3.5.4/3.5.5 while the same code works as expected in 3.5.3 and earlier (at least since 3.0.0).
Christoph wrote
If you pass only one empty array, you will be able to insert custom values (this is my experience…).
In fact in my method I do pass two empty arrays for real and display values and, as I said before, this works up to 3.5.3, not in 3.5.4. If I passed just one empty array, the second one would remain filled with the old values and the method wouldn’t work.
It is true. When using a field linked to a valuelist with both real and display values, saving of new entries (that are not found in the display values) is no longer allowed.
It makes sense because the user is operating in this case with the display values, while the dataprovider contains the data from the real values. Allowing new values would mean the user entering data (as display value) that will be saved in the dataprovider that operates with real values…
We had a issue before 3.5.4 that appeared due to this kind of behavior being allowed. New entries were saved in the DB this way and it lead to confusion. This is why this behavior has been invalidated in 3.5.4.
Could you give me an example of what display/real values appear in your valuelist? Is the display value a city or a complete address?
I want to see why you need both real and display values in your case.
Could you give me an example of what display/real values appear in your valuelist? Is the display value a city or a complete address?I want to see why you need both real and display values in your case.
Display values are complete addresses, while db values are the same addresses with some relevant information associated to those addresses when the city has more than one area code. If the display value is “Lombard (street)” the db value is something like “Lombard(street)!10210!1” where the last digit (1 or 0) indicates whether the street has more than one area code. When the value is read from the list it is used by a method that assigns the correct values to 3 different display fields. Obviously this can be done only for those cities whose street names are referenced by the postal system. For the others you must input the street names manually. So there is no valuelist (either real or display) from which to choose.
Try using:
application.setValueListItems( "name", new Array("one", "two"));
This should change the valuelist as expected (remove the real values).
As soon as I’ll back home I’ll will try it, but I have no values to put into the array so it is empty.
Neither approach seems to have any effect: any value inserted in the field when there the list is empty (e.g. associated to one or two new arrays) is removed as soon the cursor leave the field.
I tried this both with a db generated value list and a custom value list. Until 3.5.3 both worked, not considering the fact that the custom value list took much, much longer to be generated.
In case of a value list generated by the db there was no need to explicitly “void” the valuelist because there was no related data to extract from the db, therefore the valuelist was already empty.
In the case of a user generated value list (through a Sql query), I explicitly voided the arrays when there was no data available.
Both methods worked but my final choice was for the db-generated list because it was much faster.
Here is a small sample of how you can use a custom valuelist to have both behaviors you want on a type-ahead field. Note that you can also define a db valuelist (not linked to your typeahead) and then use it to get the dataset and set the values of your custom valuelist from that dataset.
Thank you Andrei, very late tonight I devised a solution similar to the one you suggest (a dbvalue list not linked to the type-ahead field) and it works. But still I preferred the way it worked before.