# Triggers origin "Browser" event on addition of instances to Flex Repeater

**URL:** <https://forum.inductiveautomation.com/t/triggers-origin-browser-event-on-addition-of-instances-to-flex-repeater/68336>\
**Category:** Ignition\
**Tags:** ignition81, perspective, scripting\
**Created:** [January 6, 2023, 10:45pm UTC](https://forum.inductiveautomation.com/t/triggers-origin-browser-event-on-addition-of-instances-to-flex-repeater/68336 "2023-01-06T22:45:11Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_Lindon](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@Michael\_Lindon](https://forum.inductiveautomation.com/u/Michael_Lindon)\
**Post date:** [January 6, 2023, 10:45pm UTC](https://forum.inductiveautomation.com/t/triggers-origin-browser-event-on-addition-of-instances-to-flex-repeater/68336/1 "2023-01-06T22:45:11Z")

</div>

I have been creating a multi-layered embedded view component to dynamically populate a Flex Repeater with user-input values. The goal is to create a component that dynamically reflects database table rows, allowing for edits and additions to said table.

This worked nicely until I started working on the change scripts. I found that when additional instances are added to a Flex Repeater (for instance going from 3 instances to 4) triggers a "Browser" change event on the Flex Repeater instance parameter, even when the changes are via scripting. Note, it isn't being triggered when I remove an instance via script. The goal was to use the "Browser" origin change script event on the instances to trigger table updates, but these events are causing me a headache. I tried filtering the events out, but it sometimes triggers more than once.

I was thinking about reporting this as a bug, but thought it safer to first see if this is expected behavior and if anyone knows a work around?

Note, we have already considered switching to a separate save button instead of save on change event, which wouldn't have this issue, but that has a lot of ramifications we are trying to avoid with this approach.

---

<div class="post-metadata">

**Author:** ![Patrick\_Chanthilack](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/patrick_chanthilack/32/42479_2.png) [@Patrick\_Chanthilack](https://forum.inductiveautomation.com/u/Patrick_Chanthilack)\
**Post date:** [January 12, 2023, 11:22pm UTC](https://forum.inductiveautomation.com/t/triggers-origin-browser-event-on-addition-of-instances-to-flex-repeater/68336/2 "2023-01-12T23:22:01Z")

</div>

Hello Michael\_Lindon,

Using the "Browser" origin change script event on the instance would be a headache to implement. What I suggest is to implement these updates with message handlers. You can use a message handler to trigger an update to refresh the bindings on the component you are working with. I have linked the documentation below on how you can further implement message handlers and refresh bindings for your project.  
[https://docs.inductiveautomation.com/display/DOC81/Component+Message+Handlers](https://docs.inductiveautomation.com/display/DOC81/Component+Message+Handlers)  
[https://docs.inductiveautomation.com/display/DOC81/Perspective+Component+Methods#PerspectiveComponentMethods-RefreshingBindings](https://docs.inductiveautomation.com/display/DOC81/Perspective+Component+Methods#PerspectiveComponentMethods-RefreshingBindings)

---

<div class="post-metadata">

**Author:** ![Michael\_Lindon](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@Michael\_Lindon](https://forum.inductiveautomation.com/u/Michael_Lindon)\
**Post date:** [January 13, 2023, 10:11pm UTC](https://forum.inductiveautomation.com/t/triggers-origin-browser-event-on-addition-of-instances-to-flex-repeater/68336/3 "2023-01-13T22:11:48Z")

</div>

I have considered messaging, but I feel they can easily cause unintended consequences and are difficult to trace the source should an issue occur, especially in the case of using multiple components on the same view. I do a lot of component re-use, to the point that most user views are 100% embedded views, so I tend to avoid them. Though I am open to convincing.

I created a bug ticket, since template repeaters shouldn't trigger a browser change event on instance creation when changed using script and will let the will of the Inductive Automation devs do as they will with it.

For my specific issue, I ended up switching tactics entirely and switched to a trust the developer approach for this situation. The solution was to add a hasChanged param and a set of togglable parameters that activate the CRUD actions, for instance a toggle that will create, delete, refresh, etc. Hope this gives flexibility to our development team to use the component as needed and gives new ideas to those interested.

Cheers.