Hello Rumen (and others),
I'd like to raise the visibility of this as it was buried in another post. After having used the "BeforeBeginEdit" event to capture a double-click event on a node, the node text disappears until you click on another node. This is highly undesireable in a "read only" tree, where the text will never be edited anyhow. I have unsuccessfully tried to capture and restore text, but can't seem to find out how to do so.
Is there way to prevent this behavior during double-click processing? Or a work-around to this apparent bug? My production date is approaching and I'm a little panicked by this strange behavior.
Thanks,Dan
Hello Dan,
I am afraid that this was just a workaround that one of the customers (in the other forum thread) suggested. Unfortunately I am too stuck with this problem, and while I will try to find a solution asap (and post a followup), I am afraid that the general problem is that there is just not a client-side double click event and the workarounds suggested have side effects.
I will try to solve this problem and write back to you, hopefully the customer who got that working will also post his custom code for that.
Please, excuse me for the inconvenince.
Thanks Rumen, I appreciate the help.
Right now I am going down the approach of capturing the text (getText() ) in the BeforeBeginNodeEdit and attempting to put it back using the setText() option, but am running into a problem with the setText code for the node:
function igtree_setText(text, innerHTML) { var e = ig_getNodeTextElement(this); this.update("Text", text); if(e.innerText != null) try{return e.innerText = text;}catch(ex){} else try{return e.innerHTML = text;}catch(ex){}}
In this code, the variable e is always null, meaning the ig_getNodeTextElement(this) call fails.
I'll keep plugging away, but my deadline is fast approaching and need to have some resolution for the disappearing text, even if it is to just catch it and put it back. Hopefully others can offer any solutions they may have found.
Thanks again,Dan
I can only say wow :) Thanks for sharing and sorry for the extra wizardry you needed to employ - but this will surely be helpful to some developers, so thanks for sharing.
For my part, I will do my best Double Click client-side event appears soon, so that you can use easier client-side code.
Alright - well I've devised a solution. It may not be the solution but at least it works for me for now. Here are the ugly details:
It's been posted here that in order to make the BeforeBeginNodeEdit work as a 'double-click' event you must return true from the event handler in order for the node to be read-only (aka Not editable). It appears that an unintended side-effect of this is that the node erases/hides/removes/whatever the node text until you click on another node. Also, when returning true, it appears that none of the other 'edit' type events get fired,such as AfterBeginNodeEdit.
While attempting to implement a node.setText() event (see above) I peeked around at some of the other events for the tree node that are not visibly exposed and I found the igtree_endedit(accept) event. Apparently the 'accept' parameter is a boolean. I was guessing (aka praying) that this event "turned off" the edit box for the node, and would thereby return my text.
In short, here's what I did to implement this approach.
One downside was that I was opening a popup window as a result of the double-click, and once I called the igtree_endedit code it returned my main form on top of the popup window. I simply captured the popup window reference in a global, and called popupwindow.focus() after calling the igtree_endedit. This results in a "flash" of the popup window, but its better than having missing node text.
Pay no attention to the previous paragraph, I simply put all processing for the popup window in the AfterBeginNodeEdit event, following the call to igtree_endedit(true) and no longer have the flashing window problem. Much nicer implementation.
I'd still like to see a better solution, but I personally have other tasks to get back to and this fits my bill for the moment. I hope it can help any of you that have the same or a similar problem.
Best regards,Dan