In latest 2015.2 version activerowchanged event is getting called even when you click outside of grid. This is called due to focusout event which is new in 2015.2. I think activerowchanged should be called when someone is changing the active row on grid.
See attached example.
Hello Manish,
The latest versions of 15.1 and 15.2 contain a number of improvements to our WAI-ARIA support. A part of this is the ability to focus each individual row/cell so that screen readers can read its role and contents. With this in mind it didn't make much sense to leave the existing activation behavior separate so we instead tied it to the focused element. When the end-user clicks outside the grid the focus is lost and the active element is cleared, firing activeRowChanged/activeCellChanged in the process. This is the intended behavior for the latest versions of the product.
Could you please give me more information about your use-case and how this change makes it harder/impossible to implement? I could probably help you with a workaround if this is the case.
Best regards,
Stamen Stoychev
on ActiveRowChanged we call web service to load some data in accordion on screen. So soon as user open accordion to see data it calls another web service call ( call ActiveRowChanged again) which result into performance issues.
Digging this up I see where the issue is. Unfortunately, the last activeRowChanged has incorrect event arguments (basically point to the last active row) so you can't really tell if the user clicked inside or outside the grid. I logged this as a bug in our internal tracking system with #214181. A support case is created on your behalf with number CAS-169874-W3N8T7, so that you can be notified when the bug is fixed. You can find your active cases under Account - Support Activity in our website. Select your ticket and go to Development Issues tab to view the status of related bugs.
Fortunately, you don't have to wait until the bug is fixed since there is a pretty straightforward workaround that won't add any overhead compared to simply getting the state from the event arguments. It is based on the fact Selection actually clears the active element internally before sending the event so you can differentiate between users clicking on rows and outside the grid by calling the activeRow method like this:
features: [
{
name: "Selection",
activeRowChanged: function (evt, ui) {
if (ui.owner.activeRow() !== null) {
// execute your logic here
}
]
I hope this helps! Please, let me know if you have any other questions or concerns!
Re: activerowchanged event issue
With the fix for bug #214181 that was logged for the issue you'll be able to check for ui.row being null when focus out causes the activeRowChanged. A workaround achieving the same behavior will be hard to implement but you can use the following before your grid definition:
$.ig.SelectionCollection.prototype.deactivate = function (suppress) { if (this._requestTrigger("ActivationChanging", true, null)) { this._notify("deactivate"); this.activeElement = null; this._requestTrigger("ActivationChanged", true, null); }}
This will overwrite the default behavior for activeRowChanged to be fired at all on focus out which should achieve your requirements.
I hope this helps!
I'm using Jquery UI 1.10.4 with Jquery 2.0.3. Could you please let me know the code for to distinguish both ?
I've also noticed it in my tests but it didn't happen nearly as often for me. Could you please let me know which version of jQuery, jQuery UI and on which browser you are testing?
In any case, after the fix the activeRowChanged events coming from focus outs have their row event arguments set to null which means that they are easily distinguishable. The fix will be available in the next SR, or if your development schedule requires it can be provided as an untested build.
Yes it called twice and it happens 10 out of 100 times.When i looked call stack for both of these , one was coming from mouse up event and another was coming focus out event. Whenever call some from focus out event ui.owner.activeRow() still contains last selected row.
Does activeRowChanged fire twice between user clicks then? I am not sure I understand the problem since activeRowChanged is expected to fire every time the user clicks on a row and therefore focuses/activates it.