[Etoys] Is there any Input Control in toys?
scott.wallace at squeakland.org
Thu Jan 24 21:50:59 EST 2008
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
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
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
> return). Is there any way to call our own method when the Enter
> key is
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
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.
> Is there any other control which we can use to solve the above mention
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Etoys