Run script upon click of checkbox

[Dana G]

I need to be able to run to separate scripts on checkboxes that reside in the same value list.

Is it as easy as creating a transparent button the size of the checkbox and placing it on top. Then make the first step in my script "set field" so that I can make sure the box gets checked?

If that's all I have to do when someone wants to check the box, what would I need to do if the clicking of that box was an accident and they needed it unchecked. I'm envisioning my users going crazy trying to unclick a box when there is a button on top that is set to do otherwise.

For some more information, the checkboxes are actions that need to be taken on a set of construction documents (blueprints). For example, if "SS" is checked - it means that it is site-specific and the project manager will be sent notification to change their project. For my second checkbox it gets a bit deeper. That one is labeled "RP" for Revise Prototype. If it is clicked it means that several people, including the client, need to be notified that they are going to have to change the prototype drawings.

Thanks for your help.

[John Mark Osborne]

Use the following script:

If [PatternCount("¶" & MYTABLE::checkbox & "¶"; "¶RP¶")]

Set Field [MYTABLE::checkbox; LeftWords(Substitute("¶" & MYTABLE::checkbox & "¶"; "¶RP¶"; "¶"); 999999999)]

Else

Set Field [MYTABLE::checkbox; Case(IsEmpty(check::checkbox); "RP"; check::checkbox & "¶RP")]

End If

You'll need to write a similar script for each check box choice, substituting the proper value. I used "RP" above but you'll need to write the same script using "SS" wherever you see "RP". But, since you have FileMaker 8 (or FileMaker 7), you can use a script parameter to pass a value of "SS" or "RP" from the button to the script. Just change the "RP" in the above script like I've done below to Get(ScriptParameter):

If [PatternCount("¶" & MYTABLE::checkbox & "¶"; "¶" & Get(ScriptParameter) & "¶")]

Set Field [MYTABLE::checkbox; LeftWords(Substitute("¶" & MYTABLE::checkbox & "¶"; "¶" & Get(ScriptParameter) & "¶"; "¶"); 999999999)]

Else

Set Field [MYTABLE::checkbox; Case(IsEmpty(check::checkbox); Get(ScriptParameter); check::checkbox & "¶" & Get(ScriptParameter))]

End If

This will make your script dynamic so you can create a single script that works for every check box button. Just pass a different text value each time you create a button for a check box button and that will modify the script each time it is run from a different button.

[Søren Dyhr]

Dynamic is way to go! But I tend to this in a single line utilizing this CF:

http://www.briandunning.com/cf/39

Because I very well might be using it for purposes elsewhere in the solution ...the syntax shines in simplicity:

Set Field[myBoxes ; XORvalues ( myBoxes ; Get(ScriptParameter) )]

...It can actually be hardwired into Set Field[ for the button, although it goes against David Kaschels advice:

The primary reason for this is that virtually all single-step buttons end up requiring more steps, forcing you to create a script for the button anyway. This is simple labor saving advice born of experience. You cannot damage anything by creating single-step buttons. You can (and will) only make a lot of extra work for yourself.

...which also seems to be the point in OP's line of questioning, the button is going to check/uncheck the box and do something as well.

--sd

[Søren Dyhr]

Hi John

You don't get it??

Now that's it out as a template as well, might you have considered the inconsequence it actually represents, just as macusers are used to forgiveness with popups, isn't this neither likely to fall completely inside the Human User Interface Guidelines issued by Apple.

We're used to choosing(fiddling) data and then issue a command via a button next to it, by merging the two concepts are you satisfying a different audience:

http://www.just-think-it.com/anti-mac.htm

I know that web interfaces kind of errode methods and puts these principles under pressure, but imagine you would like to get an estimate via several checkboxes and one of them actually completed a genuine order?? This does still put their issues with worn out methaphors in perspective - obviously are pages designed with the purpose to sell stuff, but how kindly will consumers organizations agree with such beartrap??

Now checkboxes as such are a mean to get consistent data, by removing the ability to make typos, so if you choose a cathegory with a checkbox is it going to stick, if your system is getting to some groupings of data, so the need to validate is non existent.

So what kind of scripts do you wish to pull with this feature, the only halfway fair use I can see is by attaching shortcuts to each script so a phoner could set values in a survey - without lifting a hand from the keyboard ...keeping in mind that severe mousing causes injuries!

Let me tell you where I usually use the same principle, although slightly changed. I do usually have a portal of items/selectables with a checkbox field. This field is a calc'field having the pattern counting as Johns script does, but the box itself is a list of "1".

This is the concept Jeff Almquist showed in and older Advisor years back. The point is that this calcfield sniffs if it's record ID is present in a list a relation away in the main record.

What it does is that it makes a multiline key which can be utilized for a GTRR ...which goes to a found set of selected items. When a set is established, could it be imported via inbetween tables import, say to produce new lines in an invoice.

What I say - is that this approach should be dealt with similar care as David Kachels example with letting his kid have a go with a chainsaw...

--sd

[Dana G]

John,

First of all I love your website. I have been using it for about a year and it has given me lots of ideas about how we can improve our database.

Now, as far as your script. It seems to work but every now and then I am able to click the box and it checks without running the rest of the script. It seems that it only works when the button over the checkbox is the first thing I click in the field. If I click other boxes in the field prior to selecting one with a button, the field then becomes "active" and clicking the button doesn't seem to do anything. Do you have any suggestions on how to fix that? I was thinking that I could just increase the size of the transparent button to cover the value too. That way if the user clicks the value instead of the box the script will still run.

Also, would you suggest that I creat a button for every value in an effort to keep the user from making the field "active"?

[Søren Dyhr]

You should disallow all entry to the field in browsemode and let the script take care of it, and perhaps diable further procedings in the script in findmode, and then most certainly have buttons ontop of each checkbox. John has today uploaded his version:

http://www.filemakerpros.com/SCRIPTCHECK.zip

--sd

[Dana G]

Thanks,

I think that should take care of it. I appreciate all of your help (both of you)!

[Søren Dyhr]

But as I made noises about is the userinterface violation, am I beginning to think that what you instead should use another of JMO's plentora of templates:

http://www.filemakerpros.com/LOKFIELD.zip

...although the calc' needs to cut more dedicated to the trig the autoenter only when the checkbox in question is given a certain value.

--sd