Radio Button without using a defined value

[Scottie]

Is there any way to set up a radio button so that one can click it on or
off. I just want one button, not a series and am able to deselect it.

Thanks in advance, Scottie

[Bridget Eley]

You would be better off with a check box for something like this ( to
deselect a radio button selection, you have to either select another value
or hold down the shift key).

Create a value list called "1" with one value "1". Define a number field,
then format it to the "1" value list and as a check box. Resize the field
so that only the check box shows.

Bridget Eley

in article v2Lab.520371$Ho3.87767@sccrnsc03, Scottie at
[email]scottiearmani@hotmail.com[/email] wrote on 20/9/03 8:03 AM:

> Is there any way to set up a radio button so that one can click it on or
> off. I just want one button, not a series and am able to deselect it.
>
> Thanks in advance, Scottie
>
>

[Scottie]

Thanks....I thought so. I just don't like the "weak" look of check boxes.
Thanks again.

"Bridget Eley" <bridgeteley@ihug.com.au> wrote in message
news:BB91BBD9.3429%bridgeteley@ihug.com.au...

> You would be better off with a check box for something like this ( to
> deselect a radio button selection, you have to either select another value
> or hold down the shift key).
>
> Create a value list called "1" with one value "1". Define a number field,
> then format it to the "1" value list and as a check box. Resize the field
> so that only the check box shows.
>
> Bridget Eley
>
> in article v2Lab.520371$Ho3.87767@sccrnsc03, Scottie at
> [email]scottiearmani@hotmail.com[/email] wrote on 20/9/03 8:03 AM:
>

> > Is there any way to set up a radio button so that one can click it on or
> > off. I just want one button, not a series and am able to deselect it.
> >
> > Thanks in advance, Scottie
> >
> >

>

[marianopeterson]

Part 1

-------

If you don't mind using an image container to display the radio button,
then you could just show a calculation that returns an image based on
the status of another field, which you could toggle with a script.



So, create a number field "my_number". Then create two global container
fields: "radio_on" and "radio_off". Then create a calc field that
returns a container, "my_number_display": IF (my_number = 1, radio_on,
radio_off)



Then create a script "Toggle_my_number":



IF (my_number = 1)

---my_number = 0

ELSE

---my_number = 1

END



Then place the field, "my_number_display", on the layout and link the
script to it. Finally, place appropriate icons in the global fields.
This is not necessarily the best way to do it. Its also not necessarily
the fastest. But it gives you an idea as to one way.





Part 2

-------

I think its a bad idea to implement a radio button that can be toggled.
That is not a standard UI and can be unnatural and confusing to end
users. Good UI practices dictate using Check boxes for toggle-able
items where one or more boxes can be checked and all or none can be
checked as well, and radio buttons for options that require exactly one
selection from a group and where you cannot deselect an option but
rather choose another instead. I don't know your situation, but it sure
does sound like your trying to do something with a radio button that
should be instead done with a checkbox; for the user's sake.



good luck!


--
Mariano Peterson


Posted via [url]http://dbforums.com[/url]

[Frank Dwyer]

It can be done...

Create a radio button field with a value of "1" (shrink it so only the
radio button shows if you wish)

Create a script:
If (field = "1")
SetField (field, "")
Else
SetField (field, "1")

Create a filled circle the same size as the radio button, align it over
the radio button and assign that script to it, then remove the border
and fill color from the circle.
I agree with Bridget however, a checkbox would be a better choice.



Scottie wrote:

>
> Is there any way to set up a radio button so that one can click it on or
> off. I just want one button, not a series and am able to deselect it.
>
> Thanks in advance, Scottie

[Michael Myett]

Marianos' idea is good, but I would suggest cutting down on the overhead
a little.

You only need one global container (with 2 repetitions) to store the
button images, then your calculation field will be If(my_number = 1,
GetRepetition(global, 1),GetRepetition(global, 2).

Since this is only a two state button you can get by with a one line
script, Set Field["my_number","Case(my_number = 1, 0, 1)"].
It doesn't seem like much, but its a good idea to always keep your code
as efficient as possible. It helps to keep things more manageable as
your solution gets larger.

Michael Myett

Scottie wrote:

> Is there any way to set up a radio button so that one can click it on or
> off. I just want one button, not a series and am able to deselect it.
>
> Thanks in advance, Scottie
>
>

[marianopeterson]

Very interestingly, the scripted IF ELSE is much, much faster than the
calculation IF(condition, result1, result2).



I myself was very surprised to learn this - but the difference is quite
noticeable. I used to code all the conditions in the calc for the set
field, but now I try and use the IF ELSE script blocks just because
they're so much faster. Anyway, just thought I'd pass that odd bit of
info along. :)


--
Mariano Peterson


Posted via [url]http://dbforums.com[/url]

[Lynn allen]

Michael Myett <michael.myett@verizon.net> wrote:

> Since this is only a two state button you can get by with a one line
> script, Set Field["my_number","Case(my_number = 1, 0, 1)"].
> It doesn't seem like much, but its a good idea to always keep your code
> as efficient as possible. It helps to keep things more manageable as
> your solution gets larger.

Heck, if you're going for code efficiency, try

Set Field [FieldName, Abs(Fieldname - 1) ]

No need for Case whatsoever. ;)
--
Lynn Allen Allen & Allen Semiotics
FSA Associate Filemaker Consulting & Training
[email]lynn@semiotics.com[/email] [url]http://www.semiotics.com[/url]

[Michael Myett]

Very good Lynn.

Michael Myett

Lynn allen wrote:

> Michael Myett <michael.myett@verizon.net> wrote:
>
>

>>Since this is only a two state button you can get by with a one line
>>script, Set Field["my_number","Case(my_number = 1, 0, 1)"].
>>It doesn't seem like much, but its a good idea to always keep your code
>>as efficient as possible. It helps to keep things more manageable as
>>your solution gets larger.

>
>
> Heck, if you're going for code efficiency, try
>
> Set Field [FieldName, Abs(Fieldname - 1) ]
>
> No need for Case whatsoever. ;)

[marianopeterson]

So when you write "code efficiency", do you mean the least amount of
text to accomplish the same thing, or do you mean the code that will run
the fastest?



Lynn definitely wrote the most elegent code, using the least number of
script steps and calculation steps. But, the scripted IF ELSE will
still run faster than a single set field using a calculation (even
though its an efficient calculation). It seems to have something to do
with the speed at which FileMaker can process a SET FIELD calculation vs
the speed at which it can evaluate a scripted IF condition.



I really don't understand why the scripted IF evalutates faster than a
calculation IF. In theory it would seem that the single set field with
a calculation should run faster than the scripted IF ELSE. But in
practice, the scripted IF is faster. So if you're looking for the
faster code, use:

IF

---set field (myfield, "some literal value")

ELSE

---set field (myfield, "some other literal value")

END


--
Mariano Peterson


Posted via [url]http://dbforums.com[/url]

[Howard Schlossberg]

marianopeterson wrote:

> I really don't understand why the scripted IF evalutates faster than a
> calculation IF. In theory it would seem that the single set field with
> a calculation should run faster than the scripted IF ELSE. But in
> practice, the scripted IF is faster.

The If() and Case() functions evaluate ALL arguments before coming up
with an answer. So in the following statement:

Case(
Field1 + Field2 = 1, "A",
Field2 + Field3 = 1, "B",
Field4 + Field4 = 1, "C")

FileMaker first evaluates all arguements (Field1+Field2, Field2+Field3,
Field3+Field4). Then it takes the first one that is true.

On the other hand, the IF script step only does things on an as-needed
basis, as in:

If [Field1 + Field2 = 1]
Set Field [Result, "A"]
Else
If [Field2 + Field3 = 1]
Set Field [Result, "B"]
Else
If [Field3 + Field4 = 1]
Set Field [Result, "C"]
EndIf
EndIf
EndIf

In this example, FileMaker evaluates the first arguement. If it is
false, then it evaluates the second arguement. But if the first
arguement is true, it sets the field and then skips all the arguements.

So -- two ways of doing it. The first way evaluates three arguements;
the second way evaluates one arguement. My example uses very simple
arguements, so the time difference will be unnoticeable. But imagine
some more complex calcs and you will see the benefit of example 2 over
example 1.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California
Associate Member, FileMaker Solutions Alliance

[Michael Myett]

I'm not sure with method runs the fastest, I was just trying to point
out, to the original poster, that good programming practices are
important, not that one method is better than the other.
By the way I thought Lynns code was the most elegant, as well.

Michael Myett


marianopeterson wrote:

> So when you write "code efficiency", do you mean the least amount of
> text to accomplish the same thing, or do you mean the code that will run
> the fastest?
>
>
>
> Lynn definitely wrote the most elegent code, using the least number of
> script steps and calculation steps. But, the scripted IF ELSE will
> still run faster than a single set field using a calculation (even
> though its an efficient calculation). It seems to have something to do
> with the speed at which FileMaker can process a SET FIELD calculation vs
> the speed at which it can evaluate a scripted IF condition.
>
>
>
> I really don't understand why the scripted IF evalutates faster than a
> calculation IF. In theory it would seem that the single set field with
> a calculation should run faster than the scripted IF ELSE. But in
> practice, the scripted IF is faster. So if you're looking for the
> faster code, use:
>
> IF
>
> ---set field (myfield, "some literal value")
>
> ELSE
>
> ---set field (myfield, "some other literal value")
>
> END
>
>
> --
> Mariano Peterson
>
>
> Posted via [url]http://dbforums.com[/url]

[marianopeterson]

I know what you mean about the case statement but that doesn't explain
this particular situation. The oddity here is that FMP resolves
expressions much faster in scripted IF's than in SET FIELD's. On the
other hand, SET FIELD is much faster when used with a literal value (as
opposed to an expression). I guess the bottom line is that the
performance is noticeable enough that it pays to use the scripted IFs
whenever possible (rather than bundle expressions into SET FIELD
statements).



I've put together an ultra lightweight demo to show the difference
between the two methods. I think you'll be surprised. Let me know what
you think once you've tried this out:

[url]http://mariano.petersonpages.com/demo/fmp/slow_check.zip]download[/url]
demo (7.90 kb)[/url]


--
Mariano Peterson


Posted via [url]http://dbforums.com[/url]