Automagic Forum

Currently I have for 'up', 'down', 'left', 'right' recorded gestures. These work in Action boxes which are fed by individual conditions. E.g:

Condition: global_navclick =='left' //global_navclick comes from a widget
Action: Control UI
Script: touchGesture(0,40, newList(100, 1400, 900, 1400));

All ok here!

As the direction conditions and actions run in parallel (or very close sequence), when testing, I kept on triggering the emergency stop. I adjusted the threshold and all worked but I started thinking about efficiency.

I tried replacing the four conditions with one action script, to store the script needed subsequently as text. Subsequent edit: Spotted that I'd used incorrect syntax (gn='left' rather than gn=='left' etc..)

The next action was a control UI action box.
I've tried in this (unsuccessfully) these alternatives:
but I'm either missing something (most likely) or this can't be done.

Any pointers as to what may make this work would be appreciated. Also many thanks to all the contributors here especially Martin and Desmanto whose answers and archiving have helped my scripts immensely.

When typos corrected in first code block, second line of second codeblock works.

At this time, you will need to use map object. You will start to discover more wonderful things you can do and much more efficient coding.

A map object is just like dictionary, where you mention some "key" word and it gives back the "value" meaning. In this case, you give "up" (pun intended ), it gives back 'touchGesture(0, 40, newList(500,1000,500,700))'. So you will arrange your script into a map. Then give the map the keyword, and it will give {gest} as the script you need. newMapFromValues() is to create the map from existing value. If you need a blank map, just use newMap() and later use addMapEntry() to add the key-value pair. The whole map can be defined in single line coding, but I always prefer to typed in multiple line for easier reading.

For this case, it might seems using map doesn't shorten your code significantly. But when you need to reuse the map, you will find it that it is much easier to define the map once and use it for the rest of the flow; rather than using multiple if() to check for one thing.

For your eval usage, you don't have to assign the value to {gest} first. You can actually simply use
Then about the glovar and widget; if you need the widget to set a glovar (using action script), then the glovar triggered changes and execute the flow; it is far more efficient if you change the widget action to just use action execute flow. I use this a lot, to the point that I made a flowception just to create it. (helper flow to create action execute flow in widget).

Widget execution to a flow will pass variable {gesture}, {widget_cell_x} and {widget_cell_y} (and many others variable you can check in debug dialog). You can use this to determine the source of the widget action. Example : if your widget is 3x3 action button and your "up" is at the top center block. Then tapping this will produce gesture = "CLICK", widget_cell_x = 1, widget_cell_y = 0. Changing to this method, you can then combine the cell_x and y to get the coordinate, instead of using "up", "down", "right", "left". gesture = "CLICK" is not used here if you only tap once.

Wow - thanks that was very helpful. I'd suspected that I could use map but not in the way that you suggested with the _x,_y. As you suspected this is exactly how it is set up so I'll change the code today and learn something more than I anticipated

Success!

Strangely since I built my NavToggle widget I've not used it. I probably won't ever regain the time lost to coding ...

You are more lucky to find out that you can use multiple if() in single script element. The other guy in the other forum used to build more than 20 expressions just to check the value after the input dialog. He told me that it will be so troublesome to create 240 choices!!! so he is finding a better way to do it. Once I introduced him about the map object, the whole flow simply shrank down to just only few elements.

BTW, no time is lost in coding. Everytime you invest in finding method that doesn't work, it contribute to the better scripting in the future. I sometimes build a whole giant flow just for a very specific single moment purpose and never use it anymore until now. But by building it, the experience helps me to create a better scripting block or better grand design of the flows. Until now, I still continue to use nested map/list method heavily. It helps to simplify and organized the main structure of the flow for future editing.