<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Christoph,<div><br></div><div>yes, the current implementation of #textEdited: is not perfect. It is difficult to seperate any change from user-made edits. We cannot even know whether those incoming user-input events are not generated by a script. :-)</div><div><br></div><div>If you want to get an overview of higher-level user edits, take a look at the following methods:</div><div><br></div><div>TextEditor (or SmalltalkEditor) class >> #initializeCmdKeyShortcuts</div><div><span style="font-size: 13.3333px">TextEditor (or SmalltalkEditor) class >> #initializeShiftCmdKeyShortcuts</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Here is a crazy idea: In those editor methods (e.g., #paste), we could add a pragma (e.g. "<userEdit>") and then look for a method activation with that pragma on the stack in Editor >> #userHasEdited. :-D</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">I think we cannot just use PluggableTextMorph >> #hasUnacceptedEdits: to signal that #textEdited: because that would raise too many signals.</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">Or wouldn't it? Hmmm...</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px">PluggableTextMorph >> #hasUnacceptedEdits: aBoolean</span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px"> "..."</span></div><div><span style="font-size: 13.3333px"> aBoolean ifTrue: [self textEdited: self text]. </span></div><div><span style="font-size: 13.3333px"><br></span></div><div><span style="font-size: 13.3333px;line-height: 1.5">Best,</span></div><div><span style="font-size: 13.3333px">Marcel</span></div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 18.07.2019 19:13:44 schrieb Christoph Thiede <christoph.thiede@outlook.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi all,<br><br>I did not found out whether this is a known bug/limitation: When you press<br><cmd-a>, <cmd-i> or any other shortcut that raises a read-only operation<br>into a TextMorphForEditView, #textEdited: is called. This is caused by the<br>"guess editing" in TextMorphForEditView>>#keyStroke:. I think this is an<br>unwanted behavior as some views might schedule some relevant behavior to any<br>real text edition. (For example, we are working at a sheet tool which<br>activates an edit mode when any edit is received. It is irritating to get<br>the edit mode activated whenever some text is selected via keyboard.)<br><br>I first tried to add another condition to the cheap check<br><br><br><br>but then, events like Control Paste did not raise a #keyStroke: call. Marcel<br>proposed the alternative to compare old and new contents. Personally, I<br>would not find this solution ideal, as it is possible that the view decides<br>to change its contents when the text is edited, and in this case it would<br>receive #textEdited: just after the keystroke. (Our sheet tool does so, by<br>the way. Do you think this is a non-abusing implementation? In our concrete<br>case, the alternative would be to override both PluggableTextMorphPlus and<br>TextMorphForEditView.)<br><br>Is there any existing hook to identify the latest modifying event/user<br>operation that could be used for a cheap check here? As someone who is not<br>familiar with Morphic-TextSupport, my best idea would be adding a state<br>variable (wasEdited) to the Editor, resetting it before calling super<br>keyStroke: and testing it afterwards. In case of TextEditors, it _might_ be<br>an option to consult its history (?), but that wouldn't be an universal<br>solution? I do not really find that would be beautiful solutions, and would<br>welcome any better proposals to learn from them.<br><br>Best,<br>Christoph<br><br><br><br>--<br>Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br><br></cmd-i></cmd-a></div></blockquote>
</div></body>