[Gambas-devel] ValueBox

[Fabián Flores Vadell]

>> Just is a design test. The final goal is write a ValueBox control.

>OK, cool.
>
>Actually is it a good idea. We should provide some specific controls to edit
>specific datatypes, and merge them inside the ValueBox:
>
>- Your DateBox, that may replace DatePicker.

I think that they should be merge.

>- a "MaskBox", that would be a TextBox with a mask. It could be use to edit
>things like "IP address", "emails"... I will work on that, to see if a new
>control is needed, or if TextBox can get the mask directly.

So, If you are thinking in two alternatives, seems to me that they are
TextBox and ValueBox.

But I believe that there should be improved TextBox's current
functionality and to rewrite ValueBox to improve it and to add
functionality also.

In TextBox:

- As in that example I sent you before, allow the use of String class
associated to Text property, assuming than Text is the default
property. Example: TextBox1.UCase, TextBox1.Mid(Pos, Length) - the
String argument would be innecesary.

This can seem something unhelpful, but could avoid than Gambas users
faces the desicion about use Len(TextBox1.Text) or
String.Len(TextBox1.Text). Moreover, write less code would also
allowed.

- Add search capabilities. Example: TextBox1.Text.Find(Pattern),
TextBox1.Text.FindNext(Pattern)

- Add the possibility to have a label associated to TextBox (by a
property named labeled?) so it can be located to the left or above
TextBox, depending on the user taste.

- Add in TextBox a boolean property to allow manage the
obligatoriness. Then, if the user set a named Mandatory property in a
TextBox control, Gambas should create automatically a collection with
the mandatories TextBox (or other mandatory controls too). So, the
user can set the Mandatory property and then iterates through the
collection to verify its controls.

Mask could be a static class in Gambas, so it could be used in
TextBox, ValueBox, etc. So, MaskBox could be a specialized class from
ValueBox.

>In a few words, the goal of ValueBox is being able to edit a value according
>to its datatype and/or its meaning.
>
>The datatype and the meaning is not necessarily the same thing. For example, a
>"String" and a "IP address" should not be edited the same way, but a "Date" is
>just a date.
>
>The value editor should adapt to the datatype: a (working) popup calendar for
>a date, a spinbox for a integer number within a range...
>
>The ValueBox.Type property can be an integer like now, or a string that
>describes the ValueBox meaning entirely.
>
>Let's suppose we take the last way, which is more open to the future. :-)
>
>The ValueBox.Type could be :
>
>Integer[:Format]
>Number[:Format]
>Range[:Min:Max]
>Date
>Time
>IPAddress
>MailAddress
>Color
>Boolean
>File
>URL
>Currency
>Font
>.
>
>We could take a syntax that ":" is a separator, and that everything between
>":" is a type argument.
>
>According to the type, the ValueBox will use a TextBox, a SpinBox, a DateBox,
>a ButtonBox whose button will open a specific editor... And so on.
>
>What do you think about that?

Is exactly what I infer from my test design.

I was thinking in create a base (virtual) class with the common
functionality and derived classes with a specific behavior. When the
user define a Type for ValueBox, internally a specialized class is
instantiated.

I wrote DateBox like a aggregation of 3 TextBox (Day-Month-Year). This
had simplified the encoding a little, but perhaps the result is not
very aesthetic.

However, if I generalize this class, I can write derived classes for
manage time (TimeBox, 3 TextBox for HH, MM  and SS) and IP (IPBox, 4
TextBox), at least.

Then, I refactor my code so the names have a more abstract mean
(without symbols than refers to date, day, month or year) and other
changes in order to achieve that goal. Thus I could evaluate a bit the
risk about the implementation. But I not finished yet.

So, independently of implementation,  I think that this could be the
design criteria. But, I see a problem here, Gambas just provides one
level of inheritance. So, ValueBox can't inherit from UserControl or
UserContainer, or the design criteria should be other.

Well I hope  you like my proposed changes and my ideas, but if not,
feel free to let me know (and please explain to me why)


Regards.

--
Fabián Flores Vadell
www.speedbooksargentina.blogspot.com