[Gambas-devel] ValueBox

[Benoît Minisini]

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

I won't do the previous methods, because TextBox is a native control in both 
gb.qt and gb.gtk, and so its methods must be native methods. 

All that is syntactic sugar that can be implemented by extending the TextBox 
directly in Gambas code.

There is no problem with knowing if Len() or String.Len() should be use. Len() 
returns the string length in bytes, String.Len() the number of UTF-8 
characters. 

TextBox.Length = String.Len(TextBox.Text), it is just a lot faster. 

A TextBox.Mid() function would be a little faster then String.Mid() applied on 
TextBox.Text, but marginally as the length of a TextBox string is usually low, 
and if you implement TextBox.Mid(), you will logically have to implement all 
the other methods of the String class!

Generally, if I can avoid implementing an interface (i.e. a method or a 
property), because the same feature can be implemented without too much 
penalty, or because implementing it lead to too many disadvantages, I don't 
implement it.

Too much design is as bad as too few design!

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

I don't see the need of the mask property outside of the TextBox or MaskedBox 
control, because it implies both formatting the displayed text and managing 
the key events.

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

Don't forget that the user may want to edit just a date, just a time, or both 
date and time. The same DateBox control should allow all that. And have a 
popup calendar for the date part.

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

I'm not sure if using inheritance for implementing all the possible features 
of ValueBox is a good idea. I'm not against DateBox, but I don't like having 
dozen of different controls for editing different things.

I prefer an unique interface, ValueBox, whose behaviour is entirely defined by 
its Type property. Don't forget that I want to use this control in the GUI 
database component, to easily edit database fields. I want to let the user 
have an optional gambas-specific metadata table in its database, that the 
component will use to configure the ValueBox that will edit each field.

Regards,

-- 
Benoît Minisini