Ah, I was using Firefox, which does not have that problem. But Chrome does. We’ll investigate.
Thank you walter, Maybe lose focus stop the editing mode better. If possible.
Would it be OK if we changed the default text editor so that it wouldn’t allow text editors be active in two different diagrams at the same time? (It’s always been the case that you couldn’t have two active in the same diagram at the same time.) That would prevent the situation that you have. Our testing also noticed a severe problem with Internet Explorer 11 with the situation that you reported, which would also be avoided with the change that we are proposing.
I’d like very much this motion “wouldn’t allow text editors be active in two different diagrams at the same time”! actually, we don’t need to activate two or more input at the same time, right?
you mean you will fix it in the future release of gojs, or give a workaround solution for me ?
The change will be in version 2.1.7. But you can implement it yourself by overriding TextEditingTool.doActivate to check and set a static/global variable, and to clear it in an override of TextEditingTool.doDeactivate.
Note that the problem can still arise with multiple diagrams running in multiple frames or windows. If handling that becomes necessary, you can replace the static variable flag with local storage state or something similar.
We have released 2.1.7. Please see if the situation is avoided in your app.
I tried new version, but it did not work. When I active in the first diagram , then click to the second diagram’s node to edit it did not get to edit mode. The first diagram keep the edit mode it do not Deactivate .
That is correct. The user must first finish the old editor if they want to start a new editor.
What ? how to finish ? click other diagram it MUST finish automatically, this is natural.
you mean every time user click the out side of node in diagram finish the editing then go to second diagram do same thing , and on and on … , I think it is not good design of GUI. look Excel or Other GUI design please.
One problem is that textValidation might return false, so the text editing cannot finish.
Also, when we used to automatically accept the edit when the user clicked outside the diagram, people complained – we should leave the editor in its editing state. Maybe the user wants to copy some text from elsewhere to paste into the editor.
You could try implementing a GoJS Events -- Northwoods Software that calls TextEditingTool | GoJS API on the first diagram’s Diagram.currentTool if it is a TextEditingTool.
“Doing so is only covering up the actual problem”. You said that before to me. So I found the real problem here but see it didn’t fixed.
See, I did not edit just active to edit, I hope there is have a good solution.
There is a new problem that occurs, If I active editing on the first diagram then double click the second diagram’s node, the second diagram will freeze, it can’t get focus.
We’ll investigate.
OK, in 2.1.8 we have fixed the problem with hanging, and we have made the behavior a bit smarter. If there is an active editor, TextEditingTool.canStart will call TextEditingTool.acceptText on it. If it succeeds, a new editor can start. If it fails, due to a textValidation error, then the focus remains there and a new editor cannot start.
I don’t think we will release 2.1.8 tomorrow, but I expect we will next week.
“Focus remains there and a new editor cannot start.” I want lose focus and start the new editor. That is natural.
If textValidation fails, the current text string cannot be accepted.
“cannot be accepted”. You mean it back to the previous text? it OK! because it is error right?
In the active editor mode I can’t get “GainedFocus” on the second diagram. so I can’ t do anything about that.
Try again with version 2.1.8.
Thank you very much walter, it work perfect. this is real GUI. 😄