I work daily with a MLS appliation that, during data entry (multi-tabbed dialog) for a Property Listing, provides a series of checkboxes for Attributes of a group. These Attrbutes are available individually for query building, but are presented as a concatated value in reports and export.

For example, for the group Feature_Frontage the available Attributes are: Road, Lake, River, Creek, Branch, USFS.

Sample value for Feature_Frontage: Road, Creek, USFS

A search for any of these three values will return this Listing.

This functionality can be achieved in UR but you're somewhat hampered in presenting a large number of Attributes in a Form (3-cols X 25-rows, shrinking Viewer Area to zero), or you end up with a very long batch of Attributes in the IA Pane.

Some of this can be mitagated by building child records to group some of the choices - recreate the multi-tabbed data entry dialog from the example.

Calculated Fields (Attributes) would allow for the creation of - Feature_Frontage - and available for Form, Print, or Export.

Also, as you mentioned previously, Checkboxes for Logical Attributes would be nice.

Along these lines, I've also seen Radio Buttons used as logical selectors, but the available selections are governed by a "group rule" that requires a selection of at least one value.

Originally posted by ashwken
[
Along these lines, I've also seen Radio Buttons used as logical selectors, but the available selections are governed by a "group rule" that requires a selection of at least one value. [/B]

No, it's a feature of the tabbed data-entry dialog from the example application.

Checkboxes are used and allow for multiple Attribute selection within a Group. Radio Buttons are also used for making a selection, but within the Group of available Attributes a rule has been applied (coded) that enforces uniqueness (only one selection can be made).

This is more a case of controlling data input, but I did find it to be an interersting implementation.

In the original example application the individual Attributes would still need to be selected individually for each Item, i.e., Attributes that describe the Frontage for a piece of property.

These Frontage Attributes belong to a Group (UR Catagory ???) Feature_Frontage, which on the data-entry dialog is simply a text heading, but on the Reports (and available for Export) is a calculated Attribute named Feature_Frontage.

Granted, at some point you will have a limited (to some multiple of the total number of available choices within the group) set of choices available from the existing records, but this set could be rather large and eventually become counter-productive - selection of the individual Attributes during data-entry is still required because the individual Attribute is needed for searching.

The calculated field Feature_Frontage is simply a presentation of the .T. choices of the group for a record.

It should also be noted that this example application is developed in MS-Access which is expected to offer a wider range of data-entry display and control features than UR.