Expression not accepted in Set Variable action

fmcpma

Member
Hello.

I tried to use the following expression in a Set Variable action:

{size=a[{lv=dim}]}

where

a is an array containing 2 arrays (indexes 0 and 1), each of which contains 2 integer entries (in order to create/simulate a 2 dimensional integer array)

dim is an integer variable containing 0

When I select the Expression option to assign the value to a new varaiable and enter/paste that expression, the OK button is ghosted and I cannot use it.

I think the expression should return the size of sub-array with index 0 of array a. Can someone tell me what is wrong in that expression, please?

Thank you for any answers.
 

FrameXX

Well-known member
12
34

So this is my simple grid. I want to save its values in an array. I can create an array and within it create another 2 arrays (rows) and within both arrays create 2 indexes (columns) with its values. This is what you did, but your array is named "a" and my mine is named "grid".

Now I want to save size of second row which should be 2 of course into an integer variable. So I will use row index 1 for row 2. (Indexing starts with zero) and my expression without using variable for the index itself will look like this {size=grid[1]}.

MacroDroid will be ok with this and let me press ok and the action will work perfectly and will save "2" into the row size integer variable, but what if I want to use variable instead of directly using number like so: {size=grid[{lv=row index}]}.

I will get the same problem as you. Why? The answer goes like this:

Try using the same expression but instead of saving it into an integer variable save it into a string variable. You will be now able to press ok, but if you test the action you will be presented with this output inside that string variable: {size=grid[1]}.

When you are trying to write an expression for integer variable MacroDroid is evaluating the expression you write on every change and checking if the output is a number (in that case allowing to press ok), which you can see from what has been saved to our string that it isn't in our case.

Problem is that MacroDroid evaluates the expression only once and only the index variable gets evaluated (replaced with its value). If it would evaluate for the second time it would get the number (size of row). This is of course MacroDroid problem, not your problem. I think the solution for @MacroDroidDev is to improve his evaluating algorithm which replaces the placeholders with its actual values (expressions that are more inner (inside more brackets) should be prioritized before the more outer expressions) or do it the lazy way and try to evaluate multiple times.
 
Last edited:

fmcpma

Member
Hello and thanks for your answer.

You understood perfectly what I meant (I always try to be as clear as I can) and gave me a precise answer, straight to the point. Unfortunately, that is rare :-(

As for the matter at hand, even though I didn't think of the little string variable trick you used in order to get into what Macrodroid was thinking, I was already afraid that MD wasn't properly evaluating the full expression. Of course, you nailed it. And I think this should be considered as a major bug in what is, after all, a programming language.

(I still love MD to bits, though [i would put a true happy smiley here, but it gets replaced by a horrible graphic one])
 
Last edited:

MacroDroidDev

Administrator
Staff member
Am I misunderstanding something or doing this wrong because when I try to recreate what is described here I am able to hit the ok button as shown in the screen shot.

Variables i and dim are set to integer types and the grid is as described above with a 2x2 array of arrays (each element with an integer variable).

1670251962182.png
 

FrameXX

Well-known member
Am I misunderstanding something or doing this wrong because when I try to recreate what is described here I am able to hit the ok button as shown in the screen shot.

Variables i and dim are set to integer types and the grid is as described above with a 2x2 array of arrays (each element with an integer variable).

View attachment 4049

I am sorry but we are not making fool out of you.

Screenshot_20221205-161053_Lawnchair.png

What's your output if you try to save that expression to a string? I guess it's 2. For me it's {size=grid[1]}. Only the row index variable gets evaluated for whatever reason that is.
 
Last edited:

Endercraft

Moderator (& bug finder :D)
The same issue is blocking me now...IMG_20221205_183542.jpg
But another issue is blocking me anyway so that does not change much...
 

fmcpma

Member
I'm confused.

I still get the same problem, (no OK) as confirmed by FrameXX.

But that is the developer talking… Could you (MacroDroidDev) be using an experimental, not yet released version of MD, by any chance???
 

Endercraft

Moderator (& bug finder :D)
I'm confused.

t that is the developer talking… Could you (MacroDroidDev) be using an experimental, not yet released version of MD, by any chance???
I always thought of that. I don't see how he would not be affected ?

I mean I can force it in anyway but if it doesn't work then I don't see what we can do.
If you would like to try this method, please send me the macro or if you know the MacroDroid macro structure use this macro (but it's a bit broken) : id=14891
 

fmcpma

Member
I always thought of that. I don't see how he would not be affected ?

I mean I can force it in anyway but if it doesn't work then I don't see what we can do.
If you would like to try this method, please send me the macro or if you know the MacroDroid macro structure use this macro (but it's a bit broken) : id=14891
Thank you very much for your offer, but I really want to get to the bottom of this and exhaust all "official" ways to understand and solve this issue, specially now that MicroDroidDev says it doesn't happen to him. Something must give, now…
 

fmcpma

Member
I am sorry but we are not making fool out of you.

View attachment 4050

What's your output if you try to save that expression to a string? I guess it's 2. For me it's {size=grid[1]}. Only the row index variable gets evaluated for whatever reason that is.
I can also confirm that a dialogue or a popup message using that same expression (or similar) produces the same text that goes into the string variable FrameXX is talking about.
 

Endercraft

Moderator (& bug finder :D)
Thank you very much for your offer, but I really want to get to the bottom of this and exhaust all "official" ways to understand and solve this issue
Technically this would not have really changed anything, because the expression would result in 0 (resets to default value).

I may suggest that both @MacroDroidDev and @FrameXX share their macro to see if there are any differences.
 

fmcpma

Member
I don't want to go against etiquette here, but would it be possible to get a quick update on this strange issue? The reported differences in app behavior – are they due to different builds being used, is it some kind of bug, is the matter being looked into, etc.

I only ask because I was doing a macro whose purpose was precisely to manipulate arrays and that's why I posted the initial question.

Thanks for any answers.
 

MacroDroidDev

Administrator
Staff member
@fmcpma Thanks for sharing. I have a fix for this issue which will be in the next update that I release. I'm not sure if I will have any more betas at this stage, because as I ever I am hamstrung for the pitifully slow review process by Google so need to wait for the current beta to get released before I can asses the state.
 

fmcpma

Member
In the meanwhile I seem to have found a workaround to this problem. Please see the top post if you do not know what it's all about. Basically, it has to do with not being able to use a variable as the index of an array of arrays in order to get the size of one of its sub-arrays when using the Size operator, as in {size=a[{lv=b}]}, where a is an array of arrays and b is an integer of value 0, both local. In the Set Variable dialogue, after the Expression option is chosen, one such line of code will be impossible to enter into the field, simply because the dialogue's OK button will be ghosted.

My solution involves the following steps:

1. Create your local variables, or at least the one(s) you'll be using to index the main array with the Size operator.

2. Create your array as a global, using the Variables item in the top right menu of the macro editing screen, which will open the global variables screen, but in a mode that defaults to only showing the ones used in your macro. When adding the sub-arrays, you may need to disable this option at the bottom of the screen, in order to see the array you're creating.

3. Back-arrow to the macro editing screen and make sure you have some kind of reference in your macro to the global array you've just created, such as a simple {v=my_array[0][0]} in any action, which you can delete later.

4. If you now return to the globals screen you'll see that now your array appears straight away, even with the option to only show globals your macro uses turned on, because of the reference you created to the array in the macro. You'll also notice a new option called "Convert to local" in the array's box. Tap it now and go back.

5. Again in the macro screen, you'll see that the array is now in the macro's Local Variables area and is now indeed a local. You can now use the Size operator on the array, indexing it with your chosen variable (as long as this variable was created before the array, as previously mentioned).

6. Two final tips: First, in any references to the array that you want to keep after having converted it to a local, remember to replace any v=my_array with lv=my_array. Second, when you're entering the Size expression, you must ensure that the value of the variable used as the index to the array corresponds, AT THE TIME WHEN YOU'RE ENTERING THE EXPRESSION, to a valid, existing index of the array; otherwise, once again, the dialogue's OK button will be ghosted. (You can use the Local Variables tool to adjust this value.)

Good luck.
 
Last edited:

fmcpma

Member
Message above (and the whole thread) does not apply anymore, since the bug has been corrected – for a while now, I think. Thanks, MacroDroidDev ;-)
 
Top