[Etoys] Is there any Input Control in toys?

[Scott Wallace]

On Jan 22, 2008, at 1:29 AM, surendra wrote:

> Hi all,
> We are using TextMorph  as a input control. While using TextMorph we  
> are facing following problems



Hi, Surendra,

Good questions!

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...


> 1)When all the text of the control is deleted it does not retain  its
> font size.

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...


When you bring up the halo on a TextMorph, there are three text- 
related halo-handles strung along the bottom of halo.

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.

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.)

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.

(The right text handle allows emphasis and alignment changes to be made.

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.

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.

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...


> 2)While giving the input using TextMorph if we press "tab" it will
> display error message rather than switching to another input control.

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...


> 3) If we press enter key  the cursor will move to the next  
> line(carriage
> return). Is there any way to call our own method  when  the Enter  
> key is
> pressed?

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...

One mechanism to consider is the one triggered by supplying an  
appropriate MessageSend object as a #crAction property of your  
TextMorph.

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.

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

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.


---

Sorry for the delayed and not-exactly-decisive answers -- hopefully  
more will follow later.

Cheers,

   -- Scott

>
> Is there any other control which we can use to solve the above mention
> problem?
>
> We are eagerly waiting for the responses.
>
> -- 
> _____________________________________
> Surendra Sedhai
> Content Developer
> *Open Learning Exchange*
> Website: http://www.olenepal.org
> _______________________________________________
> Etoys mailing list
> Etoys at lists.laptop.org
> http://lists.laptop.org/listinfo/etoys

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/etoys/attachments/20080124/d80ebaef/attachment.htm