View custom property dataset (from named query) not refreshing

Ignition
1

Hi All,
I have been trying to figure out this issue for a few days now and done a lot of searching. I have a custom property created on the View which pulls in a dataset from a Named Query. On the initial load of that page/view in a web browser the data is pulled in correctly with the right datetime stamp from the database showing when the query executed. However, when I try to reload the page in the browser, the data does not get reloaded and the datetime stamp is not updated from the database. The named query's cache is unchecked so it shouldn't be caching the data.

Is there something I am missing on this?

Thanks in advance.

2

Hi @dennis.powell, I am not familiar with how it works, but I have experienced similar events. Not sure if it’s how the session persists… but there are way better people on here to explain it.

In short, I can’t answer your initial question, but I may be able to assist on what you are aiming to do (maybe :sweat_smile:). I assume you require a refresh of the data based on an action, is this correct?

If so you can use the refreshBinding() script function. For example, edit the following code in the onActionPerformed event of a button to fit your circumstance: self.view.refreshBinding("custom.property")

3

Hi @matthew.ayre, I tried that on the view itself in the OnStartUp event with no luck. All I’m trying to to is have get fresh data from the database when a user clicks on the browser’s “reload/refresh” button. Right now it is not refreshing and acting like the data is cached.

4

Here is a screenshot of the page and what I’m doing. So the inital load will pull in the data and then I click on the web browser’s reload button (red arrow is pointing at it) and the page reloads, yet all the data is exactly the same as the initial page load. I also highlighted all the data that should be updated.

What is expected is that when the page reloads, the data is updated and the Date Range time to be updated. It currently is not.

image
image804×591 27.8 KB

5

This is basically by design.

To Perspective, there’s no difference between a user reloading the page and the connection briefly dropping (e.g. due to spotty wifi). Since we don’t want to always reload the page in the latter case, we don’t always reload the page in the former case.

I think the Page Startup script event will capture a reload, so you could potentially add your own handling to this scenario that way.

1 Like
6

Thanks for the reply @PGriffith. That makes sense.

I have set up a button on the page for testing purposes and I can get a table that is bound to the Named Query to rebind/reload the data. However, I can’t seem to get a custom property set on the view that is bound to the Named Query to rebind/reload.
I’ve tried the following script on the button OnActionPerformed.

vwProp = self.view.custom.CycleTimeData
vwProp.refeshBinding(self.view.custom.CycleTimeData)

I even tried setting the refeshBinding to the view and neither worked. Am I setting up the script wrong or can the refreshBinding work on a Custom Property?

7

self.view.refreshBinding("custom.CycleTimeData")

1 Like
8

@cmallonee, Thank you! That worked on the button script. I tried it on the view onStartup event and it didn’t work. I even tried the below script with no luck.
self.refreshBinding(“custom.CycleTimeData”)

I even tried a refreshBinding on the table OnStartup and it won’t refresh on a page reload from the browser.

9

As Paul said, page reload is deliberately not restarting your session/page/view. So of course the onStartup events aren’t running again. You will need something else (like the button) to make things refresh.

1 Like
10

@pturmel, Ok, I’ll go that route then. Thank you all for the help.

11

Here’s the problem you’re running into:

As far as Perspective is concerned, a browser refresh does NOT restart the page or the view, because a browser refresh is basically considered a short disconnect from the point-of-view of the Gateway. So in the past, users had no way to trigger a script if a user refreshed a page. To help, we bundled browser refresh events into triggers for the PAGE onStartup event so that users could reliably execute code during a browser refresh. We did nothing of the sort for Views. Your View is not technically directly connected to the Page, so you have no direct access (ie: from the page onStartup Event, you may not do something like self.view).

I think that we could make use of some trickery here. As of 8.1.12, Pages have a urlParams object which the View has access to.

In Page onStartup:

page.props.urlParams.refresh = True

Add a new custom property to the VIEW, and name it refresh.
Bind this new property to this.page.props.urlParams.refresh, and make sure that you set the “Overlay opt-out” checkbox to be checked.
This binding will also need a script transform:

if value:
    # only do this if the property is found and needs to be done
    self.refreshBinding("custom.CycleTimeData")
    self.page.props.urlParams.refresh = False
return value
6 Likes
12

Where do you get the 'self.page.props.urlParams.refresh'? I don't see it in the page props, nor in the docs Pages in Perspective | Ignition User Manual

Screenshot 2024-09-06 at 10.44.50

What I'm looking for is writing back to the urlParams, and seeing the url change in the browser without whole Ignition reloading.

13

It's an url parameter, so it's up to you to add it.
Putting page.props.urlParams.refresh = True will create it.

I don't think you can do that.

14

Ah, that was not my brightest moment, thanks.

But It's still not possible to write to the urlParams and seeing the change in the browser without a refresh, right?

15

Even with a refresh, I don't think what you write into page.props.urlParams will reflect back to the browser. Actually it might even be overwritten on refresh.

16

What I mean is doing this

system.perspective.navigate("/new-page?test=5")

It does give you '/new-page?test=5' in the browser, but it does not show up in the urlParams, unless you refresh. Thats unlucky if you want to rely all logic on that.

17

I'm pretty sure you need to use url navigation to pass url parameters.

18

Yup, which triggers a refresh, which is unfortunate.

19

as of 8.1.45 none of these work - EDIT - on fresh project start:

page.props.urlParams.refresh = True # page.props.urlParams doesn’t exist at page startup
page.props.urlParams = {'refresh’: True}
page.props.urlParams = dict(refresh = True)

page.props.urlParams = dict()
page.props.urlParams.refresh = True
page.props.urlParams[‘refresh’] = True

I finally settled on this (in page startup) after hours days of screwing around:

page.props.urlParams = {} # instantiate
page.props.urlParams[‘refresh’] = True # set
page.props.urlParams.refresh = True # this works too but feels fragile

Maybe there’s something special about the setter/objectWrapper but unsure if there’s any way for me to find out (or I’m just missing something)

Strangely - i could get the page.props.urlParams = dict(refresh = True) method to work by also firing page.props.urlParams.update() on a view/component startup method…. really seems like I’m just missing something at this point

refresh property (on any component - I explicitly avoid view custom props) bidirectionally bound (so i can toggle/display in a urlParams debug dock) to page.props.urlParams.refresh (this prefix is not valid) with a change script for the binding refresh/property reset (biderectional bindings prevent script transforms). Also unsure the original rationale for overlay opt-out.

be sure to empty-cache-and-hard-refresh browser and launch designer from scratch (some combination of change script triggering and page startup not firing with File > Open)

EDIT

I just realized page.props.urlParams does exist on a page refresh, just not a fresh page startup, so better quicker workaround for this specific issue (to avoid designer/gateway errors):
if hasattr(page.props, 'urlParams'): page.props.urlParams.refresh = True

FWIW, the “instantiation” method above creates the refresh property in the page.props.urlParams tree so it’s visible/selectable in binding property browser and avoids the Bad_NotFound overlay/warning in designer property tree (which itself doesn’t appear to be avoided by overlay-opt-out checkbox)

Unfortunately I’m also attempting to set other page.props.urlParams on actual page startup, not just refresh. Perhaps that’s what initially let me down this rabbit hole

Fun fact (to me anyawy): page startup in designer thinks it’s gateway scope?

20

Perspective sessions run in the gateway including all python scripts, so yep, it's in gateway scope

1 Like