If you make a valuelist, it would be nice of we could display something else in the list, than in the field!
for example, a have a field: productnumber, with a valuelist of all the products. If I select the product, I would like to see the productnumber back in the field.
This field produces than a lookup and get’s the rest of my line item
Is this possible?
personally I’d find it very confusing if you see something else than you select. Nevertheless: with all the events Servoy offers you that shouldnt be hard to build.
That’s why I use it in conjunction with a lookup field, so that if the productnumber is back in the field, it produces a lookup, and other fields are filled in!
Return in dataprovider: Productid
show in list: product name
lookups based on productid
That’s how it would work in a typical application, this would always show productnames for the end user (which they understand) yet store the productid in your database and do the lookups.
Why would you like to show product id instead? If you really want to the easiest would be to pop a dialog.
Another reason for adding that feature is column size.
We have a code field in which the codes are ‘semi-understandable’ for
MDs after they have worked with the application for awhile. However the
MDs rotate every month so we can not rely on them remembering what
the code stands for. After entering the code, we have a large text field
that is autopopulated based on what is entered in the code field. What
goes into that text field can be several paragraphs long. Ideally I would
not like to make the code field large enough to handle that - I just want it
big enough for the code itself. But I do want the value list to show at
least the first part of what will go in the auto enter text field to help the
MD be certain he is choosing the right code.
In our case the code field that triggers the lookup is only used to help
speed up data entry on a substantial number of cases. After entering the
code/lookup trigger it would be fine to programmatically get rid of the
text entered in the code field too but that removes everything entered in
the ‘real’ target text field, including any changes that one has typed in to
the text field. In fact that is a bit of a worry if after a case is finalized
someone should be browsing through the records and accidentally type
something in the code field.
The solution I suggested (pop a form in a dialog) addresses all the concerns you both mention and is easy to developer for you. None of you point out why popping a form in a dialog would not work and it’s really little work to program. Keep in mind that we have a list with thousands of features that have to be developed.
Sorry I wasn’t trying to imply that this was a big deal or needed to be addressed right away. You are right it can be handled programmatically in a dialog box and in my case the consequences of leaving it as it is aren’t bad either. Sometime though for the long term I think it is a simpler, more elegant way to be able to separate what shows in the list and what shows in the field in these type of situations (i.e. where one field is really being used as a ‘lookup’ to populate another field). It avoids the user having to deal with a popup dialog. But as I said it is certainly not a big deal for me. I was just adding my two cents worth to give another perspective on how that feature can be useful.