AESRow - how to not run query on panel start

[tpjctrl]

I have a panel which uses the AESRow panel ref and I'm having a hard time stopping it from running any queries on startup. I've traced the code in aes.ctl and it seems that when the table initialised it automatically generates a "settings change" trigger, which then causes a query to be ran and alert results to be generated. The issue I'm facing is that on the screen that the AESRow panel_ref is placed, there's other objects which trigger the aes_doStart function, so I don't really have to run any queries on startup from the AESRow panel_ref itself. Is there a way to somehow initialise AESRow so that it's ready to be used, but without it filling the table with alert data? I've tried using the $ACTION dollar param, but that seems to do absolutely nothing (or I'm using it wrong).

[leoknipp]

The AESRow is designed to run when the panel is loaded as normally there is no possibility for the user to interact with the AESRow.
When using the AEScreen you can define the behaviour when it is opened as the user can change settings during runtime.

Why do you have other scripts in your panels which are calling aes-functions?
Why not removing these functions and using the WinCC OA standard functionality for the AESRow?

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

It's a legacy panel I've "adopted" and the "outside" controls are for filtering the contents displayed on the AESRow. There's a selector for various dist systems connected to the main system and that applies a dp name filter via these three lines:

aes_doStop(_filterDP);
dpSetCache(_filterDP+".Alerts.Filter.DpList", appliedDpFilter);
aes_doStart(_filterDP);

I was under the impression that this was the way to use the AESRow, even the manual suggests this.

As for AESRow running on start up, I can just change the AESRow config to match what the "outside" filter drop down is doing on the panel, so that should take care of the initial behaviour.

[leoknipp]

Normally if you want to use pre defined filters it is done by loading the AESRow with a filter configuration using the predefined $ parameters to pass the filter configuration. This is supported and recommended procedure.
If you want to modify filters during runtime you must exactly know what to do and if several scripts are accessing the AES datapoints it can cause a race condition and unexpected behaviour.

Therefore, we recommend to define a filter configuration and to load it with the $ parameters.

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

Thanks Leopold, is the $param approach described somewhere in the documentation? or perhaps there's an example panel which covers how this is done?

Regards,
Tom

[leoknipp]

In the documentation you can find the description for openAES(). There you can also find information how to pass a configuration when opening the screen.
https://www.winccoa.com/documentation/W ... AES_3.html

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

Thanks Leopold, what's the best practice for reloading an opened screen with a different filter configuration? modify the filter dp and then simply reload the module with the use of dollar params?

Regards,
Tom

[leoknipp]

If you want to use a different screen configuration the easiest approach is the reload the screen with the new configuration.

Best Regards
Leopold Knipp
Senior Support Specialist