I have some code in a script module, called from the internalFrameOpened event, that is supposed to refresh some data in the components, and then use the fresh data to do some decision-making tasks. The problem is that the data isn’t refreshing when I ask it to, so the subsequent code is making decisions based on the previous data. This is one of the lines of code I’m using to refresh one of the components. The first line does a refresh, and then, in trying to figure out what was wrong with my code, I added the second line to see if the refreshed data was there. It’s not. The second line tells me that it still sees the data that was there from the last time the window was opened.
system.db.refresh(system.gui.getParentWindow(event).getComponentForPath(‘Root Container.txtFName’),“text”)
print system.gui.getParentWindow(event).getComponentForPath(‘Root Container.txtFName’).text
Oddly, all of the other code that manipulates the components in this script works just fine.
The problem is that the system.db.refresh function doesn’t block until the query is complete. It goes to the next line right away. The SQL query on the binding is asynchronous so you have to wait some time in your script until the query is complete. You can do something like this:import time
system.db.refresh(system.gui.getParentWindow(event).getComponentForPath('Root Container.txtFName'),"text")
time.sleep(5) # Sleeps 5 seconds
print system.gui.getParentWindow(event).getComponentForPath('Root Container.txtFName').textStill you have rely on timing. If the query takes longer than 5 seconds you will still have the same problem. It is better in this case to run the query in the script:data = system.db.runScalarQuery("SELECT Col FROM Table")
system.gui.getParentWindow(event).getComponentForPath('Root Container.txtFName').text = data
That’s right! I should have thought of that. I used that last strategy you mentioned and it worked perfectly. Thanks!
Okay, this is not a robust enough solution to work in all cases in my program. Maybe I ought to request that the refresh function someday return a value that lets the caller know when the thread is done?
What is not robust enough about running the query in the script? You are guaranteed that the value is returned before continuing on. You don’t want to get into timing issues.
As a note, every component has a propertyChange script that will let you know when the value of a property has changed. Maybe you can take that into consideration.
I’ve developed a generic search box with a table and a text box that does a bunch of stuff. The user of the box (the programmer making a new window) can enter a query in the data property, and the associated code for this box uses the data in the table to determine what to do. I don’t want the user of the box to have to mess around with queries behind the scenes. And I definitely don’t want them messing around with the code for the box. I want them to be able to simply add their query and for it to work its magic.
I see. In that case you can put those queries into custom properties so both the binding and the script have access to the same resource.