TOPIC: Improving the IdControl
#1012
Improving the IdControl 2 Years, 11 Months ago
I think IdControl can be very useful, but actually it has some bothersome issues that prevent its generic use.
A big problem is that it doesn't allow to search and sort on 'not key' fields. Essentially, the displayed record list (it pops up when you click on the little arrow on the right of an IdControl) is automatically sorted by the field specified in the 'field' parameter of the control (that is supposed to be a key). However, often is necessary to sort the record list by a field that is not a key of its table.

For example, in a list that shows the following fields of a table:

(cod, name, city)

often is very useful to search and sort by 'name' and 'city' fields, rather than by the 'cod' field. Moreover, there are many situations in which the 'cod' field has to be hidden to the user.
In these cases, IdControl allows using the parameter 'keys: (...)' where one can specify the names of those key fields for which we want to allow searching and sorting. Unfortunately, not always these fields are key fields. In the previous example, 'name' and 'city' are not keys, but we would want to search and sort on those fields.

What happens if we insert the 'keys: (cod, name, city)' parameter in the IdControl, being that name and city are not keys? In this case, it appears to me that the IdControl works nicely, but only if you don't use a 'nameField' param different from the 'field' param.
For example, this code should be ok:

Window(#(Id "mytable" field: "cod" keys: (cod, name, city)))

Instead, the following code:

Window(#(Id "mytable" field: "cod" keys: (cod, name, city) nameField: "name"))

could pop up a "Query1 not unique" error, if there exist more records with same value for 'name' field. This is because in the last row of the lookup_record method inside the IdFieldControl code, there is:

return Query1(QueryAddWhere(q, " where " $ field $ " = " $ Display(val)))

Obviously this goes in error if the query returns more than 1 record. Transforming Query1 in QueryFirst seem to be the easiest solution, but it would be wrong, because it would return always the first of the records with duplicate 'name' fields. So, I have modded it in this way:

return Query1(QueryAddWhere(q, " where " $ field $ " = " $ Display(val)
$ " and " $ .numfield $ " = " $ Display(.set_val)))


If I have understood a little the IdFieldControl code, '.numfield' should be the name of the field specified in the 'field' param of the IdControl (usually this is the key of the table). '.set_val' should contain the value related to 'field'.

Now I can use IdControl to search and sort on fields that are not keys too, but I don't know if I have missed something or if the above mod could break something in the IdFieldControl. What do you think?

Post edited by: Mauro, at: 2007/09/23 19:21
 
 
Mauro
 
#1013
Re:Improving the IdControl 2 Years, 11 Months ago
Originally, IdControl simply showed a list of values so you could pick one. (Like ChooseList). For this to work, the values had to be unique. If there were duplicates, then the user had no way to tell them apart.

But now that we show multiple fields/columns in the list, we should allow sorting by any field. (possibly multiple fields) The list just displays the records so you can pick one.

I am not sure if your change has any problems. IdControl is quite complex because of different options.

Since numfield is unique, you should not need the other (old) half of the where.

One issue is that if nameField is not unique then it will be ambiguous for the user e.g. if the field displays "Fred" and they have three Fred's then they cannot tell which one they selected. (Although when they selected it they could see other fields to differentiate.)
 
 
andrew
 
#1014
Re:Improving the IdControl 2 Years, 11 Months ago
andrew wrote:
[...]Since numfield is unique, you should not need the other (old) half of the where.
Yes, I think so but I was not sure.

One issue is that if nameField is not unique then it will be ambiguous for the user e.g. if the field displays "Fred" and they have three Fred's then they cannot tell which one they selected. (Although when they selected it they could see other fields to differentiate.)
This is not a problem. You can always create some not editable fields with a rule that fills them with other informations, so that the user had not ambiguity anymore.

Post edited by: Mauro, at: 2007/09/27 10:58
 
 
Mauro
 
#1015
Re:Improving the IdControl 2 Years, 10 Months ago
I had to hack the LocateControl, KeyFieldControl, AccessControl and the KeyListView in order to provide a non unique lookup (search) for the access control.

z
 
 
#1019
Re:Improving the IdControl 2 Years, 10 Months ago
zippy wrote:
I had to hack the LocateControl, KeyFieldControl, AccessControl and the KeyListView in order to provide a non unique lookup (search) for the access control.

z
I don't know why, but my mods to the IdControl are not enough to make work the LocateControl too with not unique lookup. Maybe the LocateControl doesn't use the IdControl. Can you post your mods?
 
 
Mauro