I’m looking for an additional example of text editing. I have seen the sample at Text Editing Examples. Maybe I am not getting it but I perceive the scope of this example revolves around alternatives to actual text entry.
I’m looking for something that shows creation of a multi-line text editing element that is the same size as the text panel it relates to. The effect I am aiming for is an in-place text editor for notes / annotations. I am not looking for rich-text or multi-font editing at this point in time.
If no examples, anything that you can give me to point me toward a solution would be great.
That is what the default text editor does. Could you give an example of what you mean that is different from the current behavior and that would work on every platform?
Sure. I guess it would be what we might call a standard ‘note box pattern’, as below.
Say you want to have a diagram where the user is allowed to add comments. You construct a vertical panel node with 3 parts. The topmost is a textBlock and will display the static text for the user name and time of their comment. The middle part is a textBlock representing the area where the comment is to be shown AND edited [very important]. The last part is a horizontal panel with action buttons.
The UI is intended to encourage the user to click on the white note textBlock and enter a comment.
Out of the box, where my comment textBox is say 200 x 150 in dimensions, the text edit input that appears is one line of text high, centres vertically in the 200px height and sticks out the sides of the 150px width by say 5px either side. Also it has no sense of constraint to the dimensions of the textBlock to which it relates.
The fact gojs provides features for overriding default behaviour is very powerful. The issue is with me not yet knowing enough to achieve the note-box pattern. But I’ve been poking around the docs, API and forum quite intensely for a few weeks now and it feels like a decent example of this use case, which must be a fairly common pattern, is missing when compared to some of the other great subject matter.
I assume some of the point in not providing an example might be that you open a can of worms by offering a sample that may not work across all platforms. I’ll gladly accept that caveat - just point the way ! Hell I’ll even donate the example here when I have something working, then you can blame me.
Some of the wrong turns I have made so far:
I have taken the approach of using a customTextEditor as per the current example, replacing the select elements with a textarea - best approach to overlaying a textBlock with an html text area to match their sizes. I set the css padding, margin and border to zero and it seems to work but would you recommend another approach?
when using textarea as a custom editor, do I have to fire the acceptText() method on the textEditingTool ?
in your example you might want to consider firing some validation - maybe to disallow a blank note perhaps ?
out of scope but worth considering - how to find the angle of rotation of the node so that one ‘could’ rotate the textarea being used as the editor by the same amount. There be dragons here cross platform, of course.
There is a codepen at http://codepen.io/JEE42/pen/wBNKNB which is a very simplified version of what I am trying to do. Please feel free to comment.
Improving the TextEditingTool is on our list of things we need to do, but we haven’t gotten to it yet. We’ll look into improving the initial size of the textarea.
Your codepen doesn’t handle scaling well – try zooming in or out before editing.
The default text editor already calls TextEditingTool.acceptText if the user presses Enter or Tab or if the user causes a mouse-down event.
You can find the effective angle for any GraphObject by calling GraphObject.getDocumentAngle().
Scaling issue - good point. As it happens in my case I am scaling using spacing so not an issue for me. Others will need to consider that point if they take the code. I guess it would need to use the scale to multiply the dimensions to keep the textarea covering the textBlock.
2. TextEditingTool.acceptText : thanks for letting me know.
Angles : thanks for letting me know.
4. TextEditingTool improvements : Potentially a big subject and very tricky cross platform if you are using HTML elements and trying to achieve WYSIWYG-style results.
IMHO you should aim to delivery clean and bullet-proof single-font text editing as a first step. If that were the default we would not be having this conversation ;-)
If after that you can delivery cross-platform WYSIWYG editing then the world will be impressed, but I would not promise it to anyone until you are confident.
PS. I am sure you could do better, but if the codepen has any worth as a sample for the gojs website then you are welcome to take it and adapt it as needed.