Michael,
A "Check box" in ARS is really just a display effect for a Selection
field. ( So all of the Selection Field design patterns apply. ) The
only real twist on the UI is that only the first (zero position) value
is visible for the selection field that is displayed as a check box.
So a quick review of ARS Selection fields.
<General info>
This field is really an integer value on the RDBMS. Before v7, all
values started at zero and were incremented by 1. So the range was
something like [0] OR [0,1] or [0,1,2....N]. However in v7 the now let
you skip numbers so the range can be [1000,5000,200000]. Each integer
value has TWO string values that map to the integer value. To explain
that I need to be more specific....
Lets say you have a "Yes", "No" "Maybe" selection field that you
assigned the integer values of 0, 1, and 2 respectively. So that ARS
can be fully localized the field "labels" need to be alterable so that
the view (one for each local) can show the "DB Name" in a string that
is correct of the local of the view. So a Selection fields value (each
integer) has N strings (one for the DB value, and one per view of the
form) that fully describe it to the end user. If a form has an English
view and a Spanish view then the "Yes" value would be displayed as
"Yes" on the English view and "Si" on the Spanish view and the integer
zero when stored on the DB from either view.
</General info>
So if you want multiple check boxes (where the user can only select
one value of the set) you must create a new Selection field for each
"check box" you want to display in the UI. However you can also have
the value stored in only one real selection field too.
It is possible to have workflow fire when a user checks on of the
check boxes and clears all of the other check boxes in the set. It can
also set the right value in a single selection field at that time too.
Let me try to explain that....
Let's say you need three check boxes for your users. (Yes, No, and
Maybe) The "Yes" field can be a real field and the other two could (
if you choose to ) be display only fields. The "Yes" field would have
it's value 0 = "Yes", 1 = "No" and it's value 2 = "Maybe". The "No" an
d "Maybe" fields could be display only and would only need a 0 value
that maps to their string. You would add active links on the "Yes"
field (on display) that would set the "No" or "Maybe" fields when it's
value is 1 or 2 respectively.
On a submit/modify/search OPERATION active links can stuff the proper
value into the first check box field. So you need an active link on
each check box UI to set the "Yes" field to the correct integer/string
value and to clear the other fields. Example: When the user checks the
third check box ("Maybe") then an active link would set (SetField) for
the "Yes" field to the value of 2(Maybe) which will leave that UI
check box as "unchecked", but will store the value to the DB all the
same. Then that same active link should set the "No" field to NULL to
clear the check (if it was set) on that UI. For the "No" field similar
workflow would be needed to set the "Yes" field to a value of 1(No)
and set the "maybe" field to NULL to clear it's check box(if it was
set).
So... Here is where the rub comes in with the above "display only"
field design.... The advanced search bar. Users would need to
understand that the "No" and "Maybe" check boxes are really not DB
fields that they can search on. Rather they would need to search where
the "Yes" field equaled "No" or "Maybe" (depending on the search they
want to do). So a valid Advanced Search Bar search might actually be:
'Yes' = "No" OR 'Yes' = "Maybe" . I know that looks very strange. So I
would suggest that the DB name for the "Yes" check box not be named
"Yes". Rather it should be named (and labeled) so that is describes
the attribute that is being stored. (Ex. 'Requester Happy?'. Then that
ASB looks like 'Requester Happy?'="No" OR 'Requester Happy?'="Maybe")
Also to help the user understand that the set of check boxes all
belong to that single label, make sure that you put the fields
together in a column/row in such a way that it makes sense to them.
I like the column approach and tend to try to put the Label for the
zero value field on top of that field and the column. Then I like to
leave the field labels for the display only check box fields to be
null. ( This helps prevent the users from trying to do advanced search
bar searches on the display only fields too. ) I also like to stack
the values in ascending order so that that check boxes line up in a
column with the "value aliases" to the right of the check boxes.
(Hum... I really should find some time to post an screen shot of this
stuff, but I hope the wordy description helps all the same for now.)
I hope that this description sparks a few ideas for how you can
achieve the UI effect your after.
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On 4/19/07, Cupp, Michael E Jr. CTR USAF AFRL/SNOD
<[EMAIL PROTECTED]> wrote:
**
This is very basic, but it's not evident to me.
I have created a Radio Button Field. I have 2 values Y and N (I'd like a
checkbox, but can't get that to work either).
When I want to select based on Y values, I get no results when I say 'Radio
Button' = "Y"
How can I create a Menu that finds only records where the Y Radio Button is
selected? Alternatively, how can I use a Checkbox and only return values
where the CB is checked?
Thanks!
Michael
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
