Avoid an Endless Loop During Event Bubbling - Greg Collins
in

InfoPath Dev

This Blog

Syndication

Greg Collins

Avoid an Endless Loop During Event Bubbling

Event bubbling means that when an event, such as the OnAfterChange event, happens on a particular data node in an XML tree, that event is passed up to the parent node, and then the grandparent node, and so on, all the way back to the root node. Thus the event "bubbles" up the tree.

Consider an XML structure like the following:

    Group1
        Node1
        Node2
            Attribute1
            Attribute2
        Node3

If all you wanted was to know whether Attribute1 had changed, you would place an OnAfterChange event handler on Attribute1. But this event would also then be passed to Node2, and then to Group1.

If however you wanted to know whether any node under Group1 had changed, you could place an OnAfterChange event handler on Group1. This is very powerful. Now you can write a single event handler to manage value changes for all of Group1's sub nodes rather than write individual event handlers on each node.

But how do you know which node the event occurred on to be able to properly respond to it? The InfoPath event object has a couple of properties that help you resolve this. They are Site and Source.

    Site: The XML node that the event handler is attached to.
    Source: The XML node that caused the event.

Thus if the OnAfterChange event handler were placed on Group1 and a change occurred to Attribute2, when the event handler was called, the Site property would be Group1, and the Source property would be Attribute2. You could use a switch statement on Source.nodeName to handle the event differently for each node under Group1.

But with all this power comes the danger and responsibility. A serious problem can occur if you handle the event on Group1 and then as part of handling that event you make a change to one of its child nodes, let's say, Node3. The change made to Node3 will now set off another round of OnAfterChange events, which will then bubble up to Group1, causing another change in Node3, which will then bubble up, and so on. This is known as an endless loop or recursion.

InfoPath catches endless loops--it will stop them after 16 calls to prevent the form from locking up. But that still doesn't solve your problem. You really don't want to ever get into an endless loop. So what can be done?

If you know that your form users will never modify Node3, but that only your code will be modifying it as part of the event handler, you can use the Site property of the event object to filter out any events that originated from Node3. If the user will be making changes as well, then you can set a Boolean flag in your code, identifying that it was the code, and not the user that made the change. Then when the event bubbles up and the flag is set, you simply reset the flag and do not make the change to Node3 again.

Using this technique you can effectively prevent endless loops, or recursion, during event bubbling. To see this technique demonstrated, take a look at my examples forms: Populating Table Row After Selection (Code), Fully Editable Drop-Down List Box and Accessing and Updating Repeating Table Row Cells.

©2005 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com.

Published Jul 07 2004, 08:04 PM by Greg Collins
Filed under: ,

Comments

No Comments
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.