You’ve found a problem with Thunkable X
You can change the property of an object, so you can change ‘in’ to something else no problem.
But right now you can’t change the property of a property of an object, so changing rcmd, param1, etc. isn’t possible with the ‘set property’ blocks at this time!
You’d have to use a kind of awkward solution where you change ‘in’ to be a whole new object every time, like this:
We know this is awkward, especially when your property has a lot of properties like ‘in’ does in your object, but it’s the best you can do right now!
We are working on this problem, so hopefully you won’t have to use a workaround for long!
It does not.
When I look at the string formed, it is formatted correctly, but I believe the content type is not JSON in this case.
How might I “set” the webapi to ‘Content-Type’: ‘application/json’ ?
@John_In_WI, since you already have a function defined with all the appropriate parameters, why not just create the object that you want to send using those parameters and then convert it to JSON using the 'generate JSON from object' block? I strongly suggest that approach, since then you don’t have to worry about generating the correct JSON syntax yourself! Plus, if you ever have to add any more parameters it will be much simpler to add it to the 'create object' block than to the 'join' block.
Mark-
I think that’s what I tried to do at the top of this thread?
The JSON data I need to POST is “nested” and I can’t change the arguments of the object of the nested part. That nested data is the stuff that needs to change with every button click.
Otherwise, you’re spot on, that’d be a much better way to go, for all the reasons you mention.
Then again, I’m new to this whole Thunkable thing and definitely don’t know the ropes yet and very likely am missing many things that are obvious.
Using it this week with a classroom full of kids that are triggering robot (and other IOT things) functions with Thunkable. So far so good.
I was suggesting just recreating the entire object (in your 'sendToRobot' function) rather than changing parts of it, and generating your JSON from that.
Working with complex nested object hierarchies performing multiple updates while using variables that have global application scope gets ugly quickly. Therefore I came up with 2 recursive functions which emulate the “Dictionary” blocks from MIT App Inventor 2 of “Get Property For Key Path” and “Set Property For Key Path”. This version does not have any error handling, so if the path is wrong, the update fails without notifying the programmer (but x.Thunkable blocks are the same). At least they get the job done with a LOT fewer blocks.
Each function requres a separate app level variable for the functions to work correctly. The click event and the DictionaryUsers list are there to illustrate the use and are not required. I’ve only done initial testing. If anyone comes up with improvements, please post for us all to enjoy.
An unfortunate limitation is that although variables are global, function are not. The way I use it is I create a form called Dictionary to hold the variables and keep copies of the functions. When another form need the function, it can be copied from the Dictionary form to the target form. Do NOT copy the variables, just the function you need.
I have also saved the example form as a public project at Thunkable
I see a few challenges for me to use your solution in my apps. It looks like your app creates a project and a sub project only (2 levels).How does your app handle deep hiearchies (3+ levels)? It also looks like you have hardcoded the number of properies. What if the JSON hiearchy is not static or under development? Finally, I’m haivng a hard time figuring out how I coould incorporate your solution into an existing project.Your solution appears heavily reliant on the UI and there are a LOT of blocks. I’m not sure how I would reuse this solution within mulitple screens in an existing app.