How correct implement special typeConverter (or exists another way)?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
vam
Reply | Threaded
Open this post in threaded view
|

How correct implement special typeConverter (or exists another way)?

vam
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: How correct implement special typeConverter (or exists another way)?

Schwab,Wilhelm K
fattigra remove_this mail.ru wrote:

> Hi.
>
> I have class Monthdays (days of month). Monthdays contains from 0 to 31
> instances  of class Monthday. Monthday is one day of month.
>
> I needed in dialog user input in textEdit strings, for example
> '1' => Monthday with one montday
> '1, 2, 3' => Monthday with three monthday.
>
> Button 'ok' in dialog enable if monthdays not empty.
>
> For begin, I implement, MonthdaysToText typeConverter. It work fine,
> but if updatePerChar for TextEdit is off. If updatePerChar is enable,
> than I have next problem - typeConverter
> convert string to monthdays on each char and user cannot type comma or
> space (more precisely, user type its, but rightToLeft and back kill any
> try input next digit).
>
> leftToRight: aMonthdays
> ^aMonthdays displayString!
>
> rightToLeft: aString
> ^Monthdays fromString: aString!
>
> How right solve this task?

I will not pretend to have the correct answer, but I can tell you what I
  did in a similar situation.  I needed to provide a numeric keypad that
allows editing of floats; it also needs to allow a user who happens to
have a real keyboard to use the keyboard and on-screen keyboard
interchangably.

I created a presenter whose model is a value holder that holds a float
being edited.  If I am reading it correctly, the number is edited in a
text edit with a null type converter (so it contains a String) and then
per character, the presenter attempt to update the "real" model from the
text.  The critical part of the update is as follows:

[
    super model value:valueConverter value.
    mostRecentValidText := text value.

] on:Error do:[ :e |
    text value:mostRecentValidText.
].

In short, it attempts the conversion, if that works, it updates its idea
of the most recent text form of the number, and otherwise uses what it
aleady has (which is initialized to an empty string).  The result is
that it never (we hope<g>) contains text that it cannot convert, and
will ignore keystrokes that do not make sense.

I have an unusually forgiving FloatToText subclass with tests to ensure
that it correctly handles intermidates such as -. which one might type
on the way to entering -.4 (of course that should be -0.4).  When in
doubt, the tests assume the value is zero until there is a reason to do
otherwise.

Does that help?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: How correct implement special typeConverter (or exists another way)?

Chris Uppal-3
In reply to this post by vam
fattigra remove_this mail.ru wrote:

> I needed in dialog user input in textEdit strings, for example
> '1' => Monthday with one montday
> '1, 2, 3' => Monthday with three monthday.
>
> Button 'ok' in dialog enable if monthdays not empty.

I probably wouldn't use a type converter at all for this.  I'd just use the
text box for text (with #updatePerChar set to true), and an explicit test in my
#queryCommand: to enable/disable the OK button.

I haven't tried that with a Dialog (I hardly ever use dialogs except for the
obvious file-open/save and so on), so there may be problems I don't know about.
But it works well in "normal" windows.

    -- chris


vam
Reply | Threaded
Open this post in threaded view
|

Re: How correct implement special typeConverter (or exists another way)?

vam
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: How correct implement special typeConverter (or exists another way)?

Chris Uppal-3
fattigra remove_this mail.ru wrote:

> DatePresenter have this problem too. If use updatePerChar and show
> defaultView (not datePicker) -- user cannot input date.

Yes, that seems likely.  The type-converter framework isn't really designed for
char-by-char input of values which have "invalid" intermediate forms.

In fact, I doubt whether it works well in char-by-char mode with conversions
which /do/ have valid intermediate forms.  I seem to remember that the control
will convert the current input into a value, and then that back to text, on
every keystroke -- which messes up the insertion point as you are typing.

    -- chris