Option set editor trick - easy option changing for conditionals!

[anon10873777]

Heyyo Bub Fam,

Found a neat little trick to make it easier to change option set selections in the editor when you’ve got a bunch of conditionals happening.

My use case:

I am making an app for disc golfers to practice putting.

The primary feature involves 41 “putt result zones” laid over a disc golf basket.

I wanted them to change colour depending upon which zone “the putt landed” (ie where they were selected)

After muck mucking about I figured out 8 conditions depending on the state of the basket element that works quite nicely (if I do say so myself)!

However, executing it involved copying and pasting the conditions from one and then manually changing the “zone” that applies from an option set list that corresponds to the same 41 regions.

Was it the best solution? Maybe not. But it works so who cares.

Anyway, 41 zones times about 10 option set zone changes times lots of editing was making me go crosseyed starring at this…

So with this ONE WEIRD TRICK I made this a heck of a lot easier!

I changed this…

to

and NOW the conditionals tab looks like THIS!

…so it’s a heckuva a lot easier to find what I need to change.

PHEW!

It was getting exhausting.

Hopefully that gives you some ideas to make temporary changes to your naming conventions to then be able to work fast in the editor!

[boston85719]

Thanks for sharing this.

What exactly did you do that helped you?

I’m not really sure what change you made that helped, or exactly what you were using this ‘trick’ for, but you may consider another approach.

In my apps, when I want to have a large set of options each with different color attributes and I want to change the color of an element based on a value of the option set that is selected, and I want to cut down conditional statements to JUST ONE, I use an approach of giving the group that is to be changed a data type of the option set, and when I select an option, I display that option as the datasource of the group to be changed, and in fact, don’t need any conditional to change the color, because my color source dynamic expression will be ‘this groups options color attribute’.

If the datasource is empty, there is no color, but when I display the data into the group, the datasource is not empty and the option selected is the datasource and the dynamic color expression is the groups datasource.

With the above approach, I am able to have as many options as I want, and I don’t need a single conditional to change the color depending on what option is selected.

BTW, if the group you are changing already has a datatype and datasource, just use an alternative group, or custom state, or URL parameter to hold the value of the selected option, and use that value in the background color dynamic expression for the group whose color you want to change. Again, no conditionals needed.

[anon10873777]

Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm…

Well, to answer the first question, which is PROBABLY solved by your approach which I dont totally get at the time of writing this sentence but will ponder while also being frustrated but also happy I am learning something new lol…

…I was stuck manually changing the option set that the condidtionals were based on.

There were 410ish of them on the page.

And I am a visual person more than verbal so even though I could find the “Over 1” option set in all the conditionals, it was hard to see and I missed a lot.

So I temporarily changed “Over 1” to “###################” so in the editor I could easily see the #'s in the editor to click on to change from the solved conditionals.

Way easier to see a block of hashes than squint and find a word in block of text all the time.

Also a bigger area to click.

Im going to contemplate your approach here while pouring some scotch in my coffee and then respond

[anon10873777]

OK…

So I think there is probably a solution with your approach that would be a lot easier…

…however, there is a wrinkle in how the conditionals work (and I didnt explain them because that wasnt the initial purpose of the post so not your fault at all) that doesnt seem to be covered in your approach…

…but again, probably could be in some way?

So a player makes a putt, and then records a result by selecting where the putt went.

Those results are “make”, “hit metal” (where they hit the basket but not make the putt), and “miss”.

To make it easier to see I am also changing colours of OTHER zones, not just the zone being selected.

That’s the difference that I don’t think is directly covered by approach described above.

For example, if they make the putt…

Hit metal…

Miss entirely…

Might be tough to see in screenshots but there are 4 different opacity levels based on the state of the “basket” element.

(Ironically I think I saw one of your posts on how to do the :append for opacity lol! and thank you!)

And there are right handed and left handed players.

Handedness matters in determining whether the missed putts “had a chance to go in” and if the made putts were “lucky” or “perfect”.

(Basically if youre right handed and you throw the disc on the left side of the basket {and vice versa} it greatly reduces the chances the disc will be made based on the spin of the disc)

So each zone has 8 conditionals…

4x opacity based on the result of the putt
2x handedness

Im sure there’s a way to do some fancy data type stuff but I was also worried about slowing performance with doing a database ping for 41 groups all the time but could be wrong on that.

[boston85719]

I’d put an option set together for your 3 types of putt results (ie: make, hit metal and miss). Then on page, somewhere (custom state, URL, datasource of group) I’d set the value of the result whenever the workflow runs for the result to be determined.

Then on the 3 different groups with the 3 different colors, I’d put a conditional for each of the 3 possible putt results and just simply hardcode the opacity value…so 3 groups, 3 conditionals on each

[anon10873777]

Yeah I have that option set with the colours but instead of hard coding the opacity values I created another option set with the Opacity #Alpha, imported the 0-100% codes into that, and set the colour opacity for each result type.

I subjected myself to all that pain because I wanted the ability to quickly fix colours and opacities from an option set instead of manually in the groups.

For example, if it turned out that the red I picked balances better with the yellow with different opacities then I dont want to go in and change each one manually for each test.

Now, all I have to do is edit the option set for one of the results and it changes everything instantly…

[anon10873777]

It’s probably not completely optimal…

…and I am not entirely understanding your solution to be fair…

…but parts of what I did make the build more flexible for a common set of values.

It fails if/when I want the colours to change based upon the user’s ability or the distances of the putts themselves.