Problem with programmatic node selection and suppressEvent flag

[Doug Loftus]

In attempting to programmatically select a node when using the 'wholerow' plugin, I've run into a little snag and wonder if either I'm not understanding something, or maybe I've uncovered an issue that Ivan might consider addressing in a future release.

(Before I go any further - I love jstree!  One of the most well thought-out constructs I've ever used.)

Problem: 

Calling select_node("someNodeId", true) does not result in a visible state change on the node - it doesn't acquire the 'selected' appearance.  

Looking at the jstree source, setting suppress = true only suppresses triggering the "change" event -  the 'select_node' event is triggered regardless of the 'suppress' flag's value.

If triggering of the "change" event is suppressed, then the jstree internal handler for this event is not invoked (in the 'wholerow' plugin), and addition of the "jstree-wholerow-clicked" class does not occur -  therefore, no state change on the node, as described above.

It also can make for some awkward event handling that a single action, like a 'select', results in both 'select_node' and 'change' events firing.  Might be cleaner and less confusing to have one event per action, if possible?

[Ivan Bozhanov]

Hi,

First of all - thanks for the kind words :)

As for the problem. The reason behind it is that the suppressEvent param is supposed to be internal only and should only be used when it is clear what not triggering the changed event will do to other modules. Basically it exists so that plugins that change selection a lot can go ahead, do their thing and fire a single changed.jstree event later manually. As a result - the select_node.jstree event was meant to be internal, since changed.jstree provides all the info you need plus it won't fire as often as select_node and deselect_node, but there is the undocumented requirement that if you suppress the changed.event when modifying the selection you have to trigger that event manually at some point.

So this leads me to the next question - why are you trying to suppress the changed.jstree event? If you don't want to do any processing every time selection is changed maybe there is something wrong with the logic, or maybe you can use an external flag to determine if your code should run. Also - there is the data.event property - which if not set will let you know that it was not user interaction that selected the node. So you can do something like:
var process = true;
$('#tree').on("changed.jstree", function (e, data) {
  // maybe work with data.event - if (!data.event) ...
  if(process) {
    // do your thing
  }
  process = true;
});
$('button').on('click', function (e) {
  process = false; // do not process the next changed.jstree event
  $('#tree').select_node("some-id");
});

Sorry if the above is not relevant to your situation. Please tell me why you are preventing the event if it isn't so that I can give better advice.

Best regards,
Ivan

[Doug Loftus]

Thanks for the reply, Ivan.

I'm trying to navigate tree nodes via key press -  up/down arrows select nodes, 'enter' or 'space' will be used to trigger the selection (as if the user had clicked the node). So both of your ideas are right on target-  I actually did take the 'flag' approach to work around it,  but I like the idea of inspecting data.event even more, so I'll explore that.

Thanks again for the explanation and advice!

-doug

[Ivan Bozhanov]

I am glad this is working for you, but didn't the built-in key navigation work for you? It has everything - up/down/open/close/to-top/to-bottom/select - all the actions are there, and it is even implemented according to the ARIA spec, as to enable users with screen readers to traverse the tree.
Just keep in mind the tree has to be focused for the shortcuts to work (just use $('#tree').focus(); once the tree is ready).
If there is a reason you did not like the built-in functionality - please share so that I can improve on it.

Best regards,
Ivan

[Doug Loftus]

Ah-  I hadn't actually discovered those capabilities.  I'm Implementing a custom combo box that needs to both display choices in a collapsible hierarchy, and provide 'autosuggest', so jstree with the search plugin is perfect for this - I just pop it into a dropdown box and it works great.  

The ideal behavior here would be to arrow-navigate among true result nodes only (I'm using show_only_matches = true, but  since a result node might be displayed within a non-result parent node, I want to skip over the parent in that case).   All of which is pretty easy since I can grab the result array out of the 'search' event.

I'll check out the built-in behavior though and see where it gets me. I'm all for writing less code, if possible :)

-doug

--
You received this message because you are subscribed to a topic in the Google Groups "jsTree" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jstree/34z2_aYnU_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jstree+un...@googlegroups.com.
To post to this group, send email to jst...@googlegroups.com.
Visit this group at http://groups.google.com/group/jstree.
For more options, visit https://groups.google.com/d/optout.

[Prahlad Yeri]

>> Also - there is the data.event property - which if not set will let you know that it was not user interaction that selected the node.

Thanks a lot for that, sir! I was stuck up with a jstree issue where I wanted to auto-select the node representing current window.location.href in a wiki I'm building. But this used to inadvertently trigger the select_node.jstree event that actually took them to that link instead of just selecting it. Using the data.event property, I can now distinguish between the user click and the programmatic auto-select.