It's looks like I can not update the Perspective table with .refreshBinding if I'm also using polling.
I just wanted to do the manual update in a button that removed items from the table so the operator would see it immediately. self.parent.parent.getChild("Table_BAD_POSTs").refreshBinding("props.data")
If I remove the polling setting where is the best place to put the refreshBinding script so it will also run on it's own? I'm guessing I can't have a Gateway Timer update the Perspective table?
I'm pretty sure this statement is not correct. What lead you to that conclusion?
The next person coming after you maintain this is, 100% of the time, not going to go looking in gateway timer scripts for an event that refreshes a query binding in a Perspective session.
I'm pretty confident you can still have the binding poll, and trigger a refresh with a "local" broadcast from a button, as @bmeyers was suggesting.
Good work figuring out message handlers they are very powerful.
I was looking through my project(s) and I actually don't have polling turned on anywhere recently. Polling usually got me in trouble since I could bog down the network accidentally. I turned it on, saved the project, and was able to trigger the refresh through a button.
Here is my code example:
# Code called by button on same *page*.
messageType = 'refresh-data-binding'
payload = {}
system.perspective.sendMessage(messageType, payload, scope='page')
# Code called on Message Handler
self.refreshBinding(props.data)
self.props.selection.selectedRow = None
self.props.selection.selectedColumn = None
I put everything back last night and it worked. ??? I have no clue why it was not working before. I tried it many times before posting. So when I saw your suggestion I was thinking I had to use a message handler to make it work.
So the correct answer is that you can do both without using a message handler and local broadcast on the button. I could last night anyway.
I just keep running into random things that don't work for some reason. I just spent some time yesterday with the default table column sort. It was working then I just had one table ignore the setting. Then I found a post saying it's a known bug if you have a binding on the table. I was going to give up on it but later found in another thread that you can make it work with the Persistent setting.
Thanks for the info and it's good to know more about message handlers, I'm sure I'll need them at some point.
The perspective.binding.AbstractPolling logger at trace level should have some good information about what's going on with the binding's internal evaluation state, though it'll be noisy if you try to test on a production system.