Servoy Forum

I'm building a form with the solution model. On that form I want to use a combo box with a value list attached to it. The value list is a existing one with 3 custom values.
This is my value list

Code: Select all

i18n:afl.lbl.mailAndPrint|1
i18n:afl.lbl.onlyMail|2
i18n:afl.lbl.onlyPrint|3


I use the following code to build the combo box:

Code: Select all

var combo = form.newComboBox(filterValue, 170, 10, 360, 28);
combo.dataProviderID = 'filterValue';
combo.valuelist = solutionModel.getValueList('filtermotreminder');;


This seems logical to me but now I face the challenge of having 3 times the first value in my value list instead of 3 different values.

Is there anything I’m missing here?

Thanks in advance

Sorry I do not have an immediate solution as I never tried that, but maybe my hints will lead to a solution, too.

I would first make the problem more simple, by using a most simple valuelist like only 1,2,3, that means without i18n in front. It could be that the i18n-keys do not translate properly so that you see three times the same value.

Also I would google "servoy getvaluelist" and "solutionModel.getValueList", which gives you some forum threads that could give you an idea how to solve it, like
http://forum.servoy.com/viewtopic.php?f=22&t=11783

Additionally you could use the valuelist on a normal combobox to make sure the vl is ok.

Thank you for you replay. Will try you're tips and tricks and see if it works!

A little late repsonse but I fixed my issue. The dataprover_id seems to be the bottleneck.
When I removed that from my code the valuelist was loaded as it supposed to be.

Ok, but how does the value finally get stored into the field? That should be the task of the dataprovider.

I see the data provider wasn't the issue here. I used a form var with the same name as the data provider that gave some issues. So I changed the name of the dataproviderID and now everything works as it supposed to be.

Fine. I think Servoy usually complains in such situations, so you might always have an eye on the problems tab in Developer.
An idea to avoid such issues is to begin form vars always with _ , Gary told me that convention.
We also put the type (b for boolean etc.) in front of a form var, and often use camel case for them.
Those naming conventions will assure that hiding of table fields will not happen.

In case you need a form var to have a temporary var that stores a field, the "_ in front" rule will help too, and you can see at once that the var belongs to the field due to its identical name.

Thanks for the tip. will discuss this with the team when we are complete again. This way we should avoid those problems. Thanks a lot for all the help!