All embedded systems, and EE types should be familiar with debouncing. When you connect a mechanical switch to the input of an electronic device, you need to “debounce” it. That is you need to add hardware or software to filter out the many extra times a mechanical switch’s contacts can bounce open and closed, in the process of just flipping it from one state to another, before it finally settles down.
I ran into something similar on an OpenSpan project I was working on. I was attempting to do something similar to this, but after I got a Created event on the control I wanted to modify, sometimes I got an exception saying the control did not exist, when I tried to modify it. I could not figure out why the control did not exist, right after I got a Created event, until finally I connected a counter to the Created event, and low and behold, I was getting multiple Created events, when I opened the web page. Which, of course, means there were multiple Destroyed events occurring, that I was not aware of. Now it was clear, just like a mechanical switch’s bouncing contacts, this web page, for whatever reason, created and destroyed itself multiple times before settling down, to being created.
Once I understood the problem, it was relatively easy to fix. I simply surround the control modification sequence in the automation with a set of Try…Catch blocks. So, after the control is created, we try to execute some modification on that control. If in the meantime, the web page is destroyed, the code fails, but the exception is intercepted, so the user is none the wiser. On the next bounce (Created event), we try again. Eventually the web page will stay created, and the code will succeed. I also disabled the control immediately after creation, and only enabled it again, after the modification code completed successfully, to prevent the user, from attempting any action during this time. If the code actually modifies the control more than once, there is no harm done.