attribute choice list needs

[tkilshaw]

I have a general need to be able to define at run time the list of choice items that can be selected from for a text attribute.

This is currently only doable at config. time by typing them in to the Choices are of the Attribute dialog, as far as I can see. This is critical for the kind of application we are designing.

Our end users will want to be able to set their own choices and giving them access to the configuration tool is not an option, both technically and pricewise.

I also want to be able, when needed, to pull the Choices from an attribute of a business object, with automatic elimination of duplicates.

Another nice feature would be the ability of Aware to add new values to the choices automatically.

Thus if I defined a Salutation attribute with choices:

Mr
Mrs
Ms

and someone adds

Dr

then the next time the choices popup was clicked it would show the list including Dr.

Finally, in many cases I want to have an empty item in a choice list, allowing the user to set an attribute to empty.

Only the first one is an absolute requirement.

thanks,

Terry

[4xjbh]

When you create the attribute there is a check box that "Other values allowed"

This allows the user to add an option at dataentry time or select from a list of existing options.

It should do what you want.

[tkilshaw]

Please reread my original post.

All Aware offers is the ability to type in a value or choose from a list.

I, minimally, need to be able to set the list of choices programatically.

The other coice list features described would be a bonus.

None of them is currently supported by Aware.

This is a fundamental requirement for our application. Without it Aware will not be a viable solution for us. It would require all of our customers to buy and be familiar with a copy of Aware with configuration capabilities, which is not an option financially or technically.

Feel free to call me in Canada at 250 707 0622 if you need clarification.

Terry

[aware_support2]

Terry,

The easiest way to do this is to define object Salutation with an attribute Title of type text. At run-time the users can add new Salutation instance for each salutation they desire and type the text into Title attribute. They can also maintain their list of salutations (you may want to add an appropriate menu item for them to maintain the list). To avoid duplications you can add a rule to Salutations that will check if the Title for a newly added Salutation already exists and then give an error message or simply delete the new instance. You can also pre-populate the list when shipping the application to the users so they do not have to start with an empty list.

Object Person could then have attribute Salutation of type Salutation with presentation options set to use dropdown and show attribute Title. On the Person form the users would simply choose the desired title from the dropdown.

This option allows the users to choose from the list, but not enter a new salutation while on the Person form. The latter can also be done in Aware IM but is just a little bit trickier. Please let me know if you are interested in this option and I will give you more details.

[aware_support]

This is also described in detail in the How To document - see "How to choose values from a list" section.

Note that you can display reference attributes in a drop down list.

[tkilshaw]

I was afraid you were going to say that.

Time for a bit of a rant.

You have designed a system in which the business object is clearly defined and maps directly to the problem domain: Account, Person, User, Transaction, and so on.

All very clear and clean. But the muddying of an otherwise clear model now begins. Every time I want a dynamic value list - to use the Filemaker terminology - I need to add a SalutationList object just to keep a list that says Mr, Mrs, Ms, but to which Dr can be added at run time, but only through a painful UI accessed somewhere else. I know that the example is trivial but the issue is not.

Your product is - to my mind - competing very directly with Filemaker and Filemaker's lookalike - Servoy. Servoy is a pure Java, rich client development tool that uses standard SQL databases and offers a heap of other functionality.

So what does Filemaker offer when it comes to value lists?

A value list lets you define frequently used text, number, date, or time values and then format the field to display the values in a pop-up menu, a drop-down list, or as a series of checkboxes or radio buttons.

When you define a value list, you can obtain the values from one of three sources:

1) From a field in the current file or another file. This method provides flexibility because the value list can dynamically update itself based on the current values in a field. If the field is in a related table, you have the option of showing all the values in the field, or only the related values. In other words you can filter the values based on a relational query, allowing for cascading value lists where selecting an item in list A causes a different set of values to appear in value list B, etc.

This automatically revoves duplicates, so if I have a SalesPeople field in a table that contains 1000 sales records that were sold by 4 different sales perople, the value list created from that table using the SalesPeople field will have 4 items, not 1000.

2) From a static list of values that you create yourself. This method is the easiest way to create a value list because you enter the values that you want the value list to display. However, it's not as flexible as basing the value list on the content of a field, because you have to redefine the value list in order to change what it displays. This is what Aware offers with its Choices.

3) From a value list already defined in another file. If the value list you want is already defined in another file, you can use the value list from that file instead of recreating it.

And when a field that uses a value list is placed on a form you also get some other options:

4) You can choose the control style you want, some of which Aware does too.

a) Drop-down List displays value list items in a list. Users can use the arrow keys or "type ahead" to select a value.

b) Pop-up Menu displays value list items as a pop-up menu. Users must select an item with the mouse.

c) Checkbox Set displays value list items as checkboxes. Users can select multiple values for a field.

d) Radio Button Set displays value list items next to a series of radio buttons.

e) Drop-down Calendar displays the current date. Users can choose another date from the drop-down calendar, or type one in. For more information, see Setting up a field to display a drop-down calendar.

5. To allow the user to enter values other than those defined by the value list, selecting "Include Edit..." item to allows editing of value list. Then the next time that value list is clicked on the new value is also displayed.

I can live with using a business object in the short term but need to know Aware's intentions with respect to improving Value list support.

In the meantime you said:

"This option allows the users to choose from the list, but not enter a new salutation while on the Person form. The latter can also be done in Aware IM but is just a little bit trickier. Please let me know if you are interested in this option and I will give you more details."

Yes please, I'd like to know how to do that.
thanks,

Terry

[aware_support]

Terry,

thanks for the rant - your detailed feedback is appreciated. We agree with you on most points, especially that implementing dynamic lists as business objects is muddying the clear model.

Yes, there are certain places where FileMaker offers a little bit more still, but you must also agree that there are many places where Aware IM offers more.

We will SURELY implement as good a support (or even better) of dynamic lists in the next version. This will be one of the top priorities of the new version. In the meantime I think it is quite workable to live with the current solution.

Regarding your last question:

To allow the users to enter a new salutation while on the Person form, as well as to choose from a list, you can do the following. As described previously you will need the Salutation object. Attribute Person.Salutation becomes a text attribute and the object will have another attribute StandardSalutation of type Salutation. Both attributes Salutation and StandardSalutation are positioned next to each other on the Person form. You will also need to add a couple of rules to object Person:

If Person.Salutation IS UNDEFINED Then Person.Salutation = Person.StandardSalutation.Title

If NOT (EXISTS Salutation WHERE (Salutation.Title = Person.Salutation))
Then CREATE Salutation WITH Salutation.Title = Person.Salutation

At run-time the user can select a salutation from the standard list, and the first rule will then copy that salutation into Salutation attribute of Person. Alternatively, the user can enter any desired salutation directly into the Salutation attribute, and the second rule will add it to the list of standard salutations (if not already there) for future use.

Best Regards,

[tkilshaw]

Thanks for your positive response. It is good to know that this issue will be addressed in your next (major?) release.

When is that due? If its dues out soonish then I can just hardwire all my choice lists for the time being.

If its of use, I'm happy to alpha/beta test for you if my existing code can be migrated.

Terry

[aware_support]

Terry,

the new release is due out around September-October (possibly earlier). Your offer to do alpha-beta testing is fantastic and we accept it gladly. All configurations will be compatible.

Best Regards