Prevent Power Table Initial Query

Ignition
1

I have a power table using a stored procedure that has parameters fed by two date pickers. As those pickers change, the table refreshes. It’s not set to auto refresh. My pickers are also setup to get their initial date from a query as well, bound to their Date property. All usually works pretty well, it gives the user a starting range and then allows them to change it if they want.

The problem comes in when the screen loads. The power table initially loads it’s data based on the picker dates, then the pickers each update their date individually, which triggers the power table to load again (for each). So the table performs three queries on load instead of one.

And depending on when the screen was saved last, the initial date on the pickers could be pretty far back. So my screen today opened using date ranges:
9/1/2017 to 9/2/2017
then 9/1/20-17 to 5/17/2018 (when the end date picker updated)
and then finally 5/16/2018 to 5/17/2018 (when the start date picker updated)

In some cases, the start date updates first, which puts the start date after the end date and creates a very fast empty query. Nobody notices that. It’s when the end date fires first that we have issues.

So what i’m looking for is a way to prevent my table from updating it’s data until my date pickers are ready. I tried having the power table disabled, but that does not prevent it from updating it’s data. I have the method worked out to know when it’s time to update, I just can’t see a property or method to disable the data query.

My last resort is to modify my stored procedure and pass in the readiness and only query at the database level when ready, but that’s kinda cheesy.

Thoughts?

-MK

2

You can’t stop it. Consider using propertyChange events where needed to queue up a background operation, with slight delay (1/10 second perhaps), storing the last queried parameters within that background event, and only executing later when they change again.

3

Thanks. That’s what I was afraid of.
I was hoping there would be a property to control if the table data was to refresh. Maybe we need another option on the SQL binding that only fires when scripted to do so.

Another way would be to create two custom properties for the dates on my table, bind the query to them and then bind the custom properties to my pickers with an expression that looks to see if the pickers are ready. I already have a method to know when the pickers have been initially updated.

That might be the easiest for someone else to follow behind me and know what i was doing, or rather for me when I look at it 9 months later and ask “What the heck was I doing?”

4

Using the state variable in an objectScript() binding might be an attractive solution.