Thanks.  I didn't know about the dropDownAsChild option, and I see your point about the chopping off issue.

From your examples, it does seem like a risk to trust the event bubbling to work properly.

Hi Chad,

Actually igCombo has option to create drop-down list as a child of main SPAN. So, events will "buble".
$('#combo1').igCombo({
 dropDownAsChild: true,
 dataSource: ["one", "two", "three", "four"]
});

However, in this case, as you probably should guess, the drop-down element will be locked in the possible containers of igCombo. For example, if any container of igCombo has overflow, position and small size, then drop-down list will be chopped and user will not be able to properly use it. That was the reason to use false as default value for that option. The default parent of drop-down list in igCombo and igEditor is the body.

I think, that most widgets will have problems with hadlers, which you try to use with combination of selectors and "on". In my first response I provided sample with slider (default jquery ui widget) where "on" fails completely. Another example can be dialog, where the actual "target" element has nothing to do with dialog-element, target is a filler for content of dialog.

Well,

I found a way to make this work.  You reminded me about the list items being stored off to the side, and I realized the event might not be bubbling up through my target selector.  If I use this syntax:

        $('body').on('igcomboselectionchanged', 'div.ui-igcombo-list', function () {
                    alert('hello');
                });

The event is fired.  However this particular version will fire for any combo on the page.  I could probably come up with a selector for the specific list items, but at least now I know what is going on.

I don't understand why the list items are not descendents of the original combo target.  And, if they have to be placed way off to the side, why isn't the name or id of the original target incorporated somehow into the generated html.  It is difficult to tie a combo to it's specific list items.  This presents a problem also in WATIN testing.  If I want to verify that a combo is loaded with the correct values, the technique is not straight forward, and is highly dependent on the current igCombo implementation.

Thanks for your help and responsiveness.  I'll have to decide if delegated events are worth it.  A big chunk of the javascript complexity in a view is tied up in re-wiring DOM elements that are replaced by AJAX.  I was attracted to the idea of cutting a lot of that overhead out.

Hi Chad,

I tested again
$(document.body).on('igcomboselectionchanged', '#combo', function() { alert('hello'); });
and to my surprise, it indeed worked for clear button and failed for click mouse on list item.
I suspect that it is somehow related to structure of html elements involved in events. The clear button is a child of original SPAN, but an item in list is dynamically built LI located in dynamic DIV.

Unfortunately I am exactly the same user of jquery as you are and I have no control over its functionality or explanations for possible problems. In the past I few times tried to debug and experiment with its logic, but that is basically dead end, because newer versions may come with very different implementations of same features. Whatever local fixes or works around for older versions are applied, they lose sence in newer versions or worse: can destroy functionality.

Under complex events I meant custom events raised by widgets, compare to simple events raised by a browser.

For example, if widget myWidget exposes event myCustomEvent, then application may process it explicitly (that is the most preferable and reliable way) by following:

$('#idOfElement').myWidtget({
  myCustomEvent: function (evt, ui) { alert('hi'); }
});

Or application can process it using bind:
$('#idOfElement').bind({ mywidgetmycustomevent: function(evt, ui) { alert('hi'); } });

If myWidget overrides the widgetEventPrefix, then that value should be used. For example, if
widgetEventPrefix: "myEvt",
then handler should be following:
$('#idOfElement').bind({ myevtcustomevent: function(evt, ui) { alert('hi'); } });

All that is documented on jquery web site.

I recommend you to use only those 2 approaches, rather than to dive into exotic and unreliable stuff like delegate, on, live, etc.

Viktor,

Thanks for the tip on the selectors.  I'll leave the node-names out in the future.   I am also glad you could reproduce the behavior I was seeing.  However,  I would still like to use the delegated events.  I guess I can roll back to JQuery 1.4.4 if the bug is definitely with them.  Can you explain more what constitutes a complex event?  As you noticed, the on() with selector works fine for simple events.  I would like to know how I should search the JQuery forums to see if this is a known issue.

As a side note, I discovered that clicking the circle "x" icon that clears the combo will fire the selectionchanged event even if it is attached with the on+selector mechanism.  However, choosing items in the list does not fire the event.  I am not sure why that is, unless the clear operation fits into what a "simple" event is.