Getting plugin states!

[Jhonazo]

Hi killerboss, great SDK, thanks!
I note that it is not possible to get the plugin static states. Of course, I am aware of Client.getStatelist(), but this gives you only the last updated states, so it is not very useful. My question is: can you make a function to get all the states of the plugin, or is it responsibility of coder to keep a copy of all states and update them appropiately?
I wrote a script that handles toggle buttons, I am using plugin states, not button states, and I am using the techique of tracking the state values by myself, but this cumbersome and error prone, so, if your SDK is tracking the state values, it will be very helpful if you expose these values in your API.
Best regards

[KillerBOSS2019]

Hello @Jhonazo thanks for reaching out. It is possible to track those static states you can do this quite easily if you use the python version of the entry.tp where the data are stored in the python dictionary format. Then in your main program you can get all the states and update data as you receive. So I don't think there's a need for the sdk itself to do all that so I believe it's the developers job to do that. But again we do have the python dictionary entry.

[KillerBOSS2019]

https://github.com/KillerBOSS2019/TouchPortal-API/blob/main/examples/plugin_example.py

You can look at that on how you can store entry.tp data inside python itself. Then you can access all the static states. If you have any questions feel free to ask!

[Jhonazo]

sorry I forgot to mention that when I refer to this dict, I refer to 'Cleint.currentStates' dict, which is returned by 'Client.getStatelist'

[Jhonazo]

I made some tests and I found what the problem is: the 'Client.currentStates' dict is not updated or created with all the states and their default values at the beginning of the connection, it is easy to do if the user wrote the entry.tp structure in the python script, if not, I don't know if touch portal can give you that info (states and default values) on request.
One workaround is to call 'Client.stateUpdate' at the beginning for each state with their default values, but this will trigger events on touch portal, which can be desirable (start a toggle button with its right visual state)
Cheers

[KillerBOSS2019]

I don't know what your trying to do. but this is unnecessary. like why do you need to track every single one of them?

[Jhonazo]

Yep, I am more interested in the state values that in the state changes. I think the solution is simple: just adding and additional parameter to the function 'Client.stateUpdate': 'def stateUpdate(self, stateId:str, stateValue:str, fireEvent=True)', then if firedEvent is True (default) it will send the state update to Touch portal. In this way, your SDK will be backwards compatible, and if an user wants to track every single state, he just need to call 'Client.stateUpdate' for each state with their respective default values at the beginning of the comunication, the 'firedEvent' parameter is in case the user does not want "plugin state change events" at the beginning of the comunication.
Anyway, since I need these events to be fired at the beginning, I don't really need that functionality, I just will call 'Client.stateUpdate' for each state. But I am almost sure that other users won't need those initial events.
Cheers.

[Jhonazo]

why do you need to track every single one of them?
Just think in this scenario: you want to create toggle buttons, handled by plugin states not button states. Then, at the beginning if you press a button in your phone/tablet, your plugin will receive an action with some text that corresponds to that button, that text (button), corresponds to one state, then obviously you want to commute (switch) that value (0 -> 1, 1 -> 0), but what value you will commute if the function 'Client.getStatelist' gives you an empty list? So, right now, the only way to do this is by creating a parallel state dict with default values and update them with every stateupdate. I found, that the same can be achieved if I call stateupdate for each state at the beginning, so the bottom line, is yes, there are some situations in which one will need to track all of the states, and this is just a simple toggle button situation, I think it can many more scenarios when this tracking will be necessary.
Cheers