I attach this to an integer dataprovider as a radio presentation. Works fine.
I also show this same record info in a table. The dataprovider in the table has Text_Type but shows the integer as expected. If I attach the valulist to this table data provider I get the error that the valuelist was created for an integer, and I’m attempting to use it for a text field - which of course I’m not. The data provider is still an integer - but the display needs it to be shown in a text field type (there is no number display type).
What’s the work around for this error - or have I missed the point altogether??
david:
Create the same value list twice – use one for the integer field and one for the text field.
My point though David (and thanks for the reply BTW) is that both fields are to display the same information (an integer result).
Why in Servoy is one (text_field) considered to be a text dataprovider (and it’s not) and yet where its used on an radio buttons display its accepted as an integer.
If I re-create the Custom VL it will still be an integer list - so is it that Servoy somehow ‘captures’ the the VL on first use (in this case radios - as an integer), and by recreating it and using against a text_field first time that version will be captured as a text dataprovider (though it will be saving an integer in the db).
there is one rule, you cant use the same valuelist on different types of columns
So if you have a field (doesnt matter what kind of field) that is build on an integer column/dataprovider and you have a field that is build on a text column/dataprovider then you cant attach the same valuelist to both of them.
jcompagner:
no i am confused you are saying the above post:
The dataprovider in the table has Text_Type
So what is it?
there is one rule, you cant use the same valuelist on different types of columns
So if you have a field (doesnt matter what kind of field) that is build on an integer column/dataprovider and you have a field that is build on a text column/dataprovider then you cant attach the same valuelist to both of them.
Sorry Johan - the dataprovider is an integer - I was refering to the form - rather than the db.
So the Db col is an integer. The valuelist refers only to an integer but in my form the display is ofcourse a text_field.
So my second post to David stands:
My point though David (and thanks for the reply BTW) is that both fields are to display the same information (an integer result).
Why in Servoy is one (text_field) considered to be a text dataprovider (and it’s not) and yet where its used on an radio buttons display its accepted as an integer.
If I re-create the Custom VL it will still be an integer list - so is it that Servoy somehow ‘captures’ the the VL on first use (in this case radios - as an integer), and by recreating it and using against a text_field first time that version will be captured as a text dataprovider (though it will be saving an integer in the db).
This seems very non-intuitive to me?
Can you suggest if my understanding is correct? Is there work-around or do I really need to make two valulists?
places 2 fields on the form, one of type text field one of type radio’s (with that integer variable as the dataprovider on both)
both get the same valuelist with the valuelist data you specified above.
This works fine for me.
If i click on the radio i see the text field being updated. If i select in the text field another value i see the radio being moved.
That is just plain weird Johan - yesterday I couldn’t get this working at all and had to remove the VL from the second form! Today when I re-attach the VL to the table view its working!!!
Just another Servoy mystery I guess! I’ve had this in the past too though so there is definitely something - or some order that must be followed to get it all working! Perhaps the numerous reboots of developer I’ve made since yesterday has cleared something?
I noticed that behavior in the past, usually closing the developer client and opening it again solved it. I’ve never been able to reproduce it consistently and create a case though.
ngervasi:
I noticed that behavior in the past, usually closing the developer client and opening it again solved it. I’ve never been able to reproduce it consistently and create a case though.
Thanks Nicola - I was almost reaching for the valium then - thought I’d lost it completely!