<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Jan 22, 2008, at 1:29 AM, surendra wrote:</div><div><div><br><blockquote type="cite"><div><font class="Apple-style-span" color="#000000">Hi all,<br>We are using TextMorph as a input control. While using TextMorph we are facing following problems</font></div></blockquote></div></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>Hi, Surendra,<div><br class="webkit-block-placeholder"></div><div>Good questions!</div><div><br class="webkit-block-placeholder"></div><div>More complete answers will be forthcoming soon (hopefully) but we didn't want to let your questions go completely unanswered for too long, so here are some interim notes...</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><div><blockquote type="cite"><div>1)When all the text of the control is deleted it does not retain its <br>font size.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>This has been, long-term, a very annoying issue, and one that we're now considering a new solution to... stay tuned. But the following background information may be useful in the meantime, particularly to anyone wishing to help contribute to the ultimate solution here...</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>When you bring up the halo on a TextMorph, there are three text-related halo-handles strung along the bottom of halo.</div><div><br class="webkit-block-placeholder"></div><div>The left-most of these is the one most people use most of the time -- it allows you to choose the font and size to apply to the current selection.</div><div><br class="webkit-block-placeholder"></div><div>The central text handle is the the only one that actually affects the TextMorph's "text style", which is all that is remembered by the morph when you delete all characters (information about font changes is retained in the text's "runs", which disappear when there is no text.)</div><div><br class="webkit-block-placeholder"></div><div>I think that probably very few people are aware of the subtle differences between these two handles. Nor should they have to be, in the long run. But for now we have to contend with this somewhat strange way that Squeak text-style information is handled.</div><div><br class="webkit-block-placeholder"></div><div>(The right text handle allows emphasis and alignment changes to be made.</div><div><br class="webkit-block-placeholder"></div><div>When you delete all text, as mentioned above, all that is remembered is the TextMorph's "textStyle", which may or may not overlap much with the text properties of the characters when the morph had actual characters present (because explicit style information will typically be found in the runs, which often completely supplant the style information the . In any case, the style itself does not specify which *size* to use (the style contains the full range of sizes available in a font family) so the size of any recently held text has no place to be remembered.</div><div><br class="webkit-block-placeholder"></div><div>The solution we're contemplating would add an extra variable to TextMorph devoted to remembering prevailing font characteristics from when the text was last non-empty.</div><div><br class="webkit-block-placeholder"></div><div>In the meantime, note that if you programmatically set the TextMorph's textStyle to the style you wish it to bear by default, this can help the situation, though if the user subsequently changes sizes using the left-side text halo, as mentioned above, that information will still be lost if the users temporarily deletes all text...</div><div> </div><br><blockquote type="cite"><div>2)While giving the input using TextMorph if we press "tab" it will <br>display error message rather than switching to another input control.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>Normally, if the "tabAmongFields" preference is true, the behavior you are hoping for is what you should be getting: if keyboard focus is currently held by a TextMorph, and you hit "tab", the selection will continue to the "next" TextMorph on the desktop, etc. Since you are not experiencing this, perhaps you have the tabAmongFields preference set to false? In any case, I wonder what the error message you are getting is -- I've not seen any errors occasioned by simply hitting tab within a TextMorph. Perhaps you could email me a project that shows the problem you describe? It would be good to get to the bottom of this...</div></div><div><br class="webkit-block-placeholder"></div><div><br><blockquote type="cite"><div>3) If we press enter key the cursor will move to the next line(carriage <br>return). Is there any way to call our own method when the Enter key is <br>pressed?</div></blockquote><div><br class="webkit-block-placeholder"></div><div>There are a number of things available -- arguably too many! -- to address this kind of need, though what the right answer should be for your needs might take some thinking about...</div><div><br class="webkit-block-placeholder"></div><div>One mechanism to consider is the one triggered by supplying an appropriate MessageSend object as a #crAction property of your TextMorph.</div><div><br class="webkit-block-placeholder"></div><div>To get an idea how this works, open an Inspector on some TextMorph that's on your screen and in the bottom-pane of that inspector evaluate the expression: "self crAction: (MessageSend receiver: self selector: #flashBounds)". Now whenever the user hits RETURN from within that TextMorph, notice that the #flashBounds action is triggered.</div><div><br class="webkit-block-placeholder"></div><div>You could harness this capability in any of several ways, one of which, for the most control, would be to create our own custom subclass of TextMorph in which you implement the kind of action you want to trigger, and then set your textMorph up for such behavior by setting its crAction property</div><div><br class="webkit-block-placeholder"></div><div>Another approach would be to use the morphic EventHandler mechanism. Give you morph a keyStrokeRecipient and a keyStrokeSelector, implement a method with the name you chose for the keyStrokeSelector, and in that method look at the character typed and dispatch accordingly.</div><div><br class="webkit-block-placeholder"></div><div><br></div><div>---</div><div><br class="webkit-block-placeholder"></div><div>Sorry for the delayed and not-exactly-decisive answers -- hopefully more will follow later.</div><div><br class="webkit-block-placeholder"></div><div>Cheers,</div><div><br class="webkit-block-placeholder"></div><div> -- Scott</div><br><blockquote type="cite"><div><br>Is there any other control which we can use to solve the above mention <br>problem?<br><br>We are eagerly waiting for the responses.<br><br>-- <br>_____________________________________<br>Surendra Sedhai<br>Content Developer<br>*Open Learning Exchange*<br>Website: <a href="http://www.olenepal.org">http://www.olenepal.org</a><br>_______________________________________________<br>Etoys mailing list<br><a href="mailto:Etoys@lists.laptop.org">Etoys@lists.laptop.org</a><br>http://lists.laptop.org/listinfo/etoys<br></div></blockquote></div><br></div></div></body></html>