Various syntaxes for text edit mask
4,134 views
Skip to first unread message
Vadim Zeitlin
May 31, 2012, 10:04:55 AM5/31/12
to wx-dev
Hello again,
I decided to look at what different other "masked edit" implementations
use for mask syntax. Here are the ones I found, for reference:
* Microsoft ActiveX control
http://msdn.microsoft.com/en-us/library/e4cw90af(v=vs.71)
* Delphi masked edit
http://docwiki.embarcadero.com/Libraries/en/Vcl.Mask.TMaskEdit
* Qt line edit mask
http://doc.trolltech.com/4.7.1/qlineedit.html#inputMask-prop
* GTK masked entry widget
http://gtkwidgexts.sourceforge.net/docs/tutorial.html
* Java mask formatter
http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/text/MaskFormatter.html
* jQuery masked input plugin
https://github.com/digitalBush/jquery.maskedinput
The conclusion is that more or less everybody uses the same conventions:
# Required digit.
9 Optional digit.
A Required alphanumeric character (i.e. letter or digit).
a Optional alphanumeric character.
C Required character (any printable).
c Optional character.
> Convert all following characters to upper case.
< Convert all following characters to lower case.
\ Escape the next character.
There are some minor variations but absolutely nobody uses wxPython "A/a"
for "upper/lower" case letter while still having required/optional
distinction so I have a feeling that the original author of wxPython
control might have misunderstood how did it work in the other controls.
And as much as I'm not supposed to say it, I think Qt syntax is the most
consistent of all of them so if we really want to have a standard mask edit
control and not something "advanced" using regex-like syntax I proposed, it
might be not such a bad idea to copy this syntax (just to be 100% clear,
I'm speaking about syntax only here, not the code).
Regards,
VZ
I decided to look at what different other "masked edit" implementations
use for mask syntax. Here are the ones I found, for reference:
* Microsoft ActiveX control
http://msdn.microsoft.com/en-us/library/e4cw90af(v=vs.71)
* Delphi masked edit
http://docwiki.embarcadero.com/Libraries/en/Vcl.Mask.TMaskEdit
* Qt line edit mask
http://doc.trolltech.com/4.7.1/qlineedit.html#inputMask-prop
* GTK masked entry widget
http://gtkwidgexts.sourceforge.net/docs/tutorial.html
* Java mask formatter
http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/text/MaskFormatter.html
* jQuery masked input plugin
https://github.com/digitalBush/jquery.maskedinput
The conclusion is that more or less everybody uses the same conventions:
# Required digit.
9 Optional digit.
A Required alphanumeric character (i.e. letter or digit).
a Optional alphanumeric character.
C Required character (any printable).
c Optional character.
> Convert all following characters to upper case.
< Convert all following characters to lower case.
\ Escape the next character.
There are some minor variations but absolutely nobody uses wxPython "A/a"
for "upper/lower" case letter while still having required/optional
distinction so I have a feeling that the original author of wxPython
control might have misunderstood how did it work in the other controls.
And as much as I'm not supposed to say it, I think Qt syntax is the most
consistent of all of them so if we really want to have a standard mask edit
control and not something "advanced" using regex-like syntax I proposed, it
might be not such a bad idea to copy this syntax (just to be 100% clear,
I'm speaking about syntax only here, not the code).
Regards,
VZ
Manolo
May 31, 2012, 1:47:37 PM5/31/12
to wx-...@googlegroups.com
> I decided to look at what different other "masked edit" implementations
> use for mask syntax. Here are the ones I found, for reference:
> use for mask syntax. Here are the ones I found, for reference:
> And as much as I'm not supposed to say it, I think Qt syntax is the most
> consistent of all of them so if we really want to have a standard mask edit
> control and not something "advanced" using regex-like syntax I proposed, it
> might be not such a bad idea to copy this syntax (just to be 100% clear,
> I'm speaking about syntax only here, not the code).
Qt syntax seems good. The code... I'm not interested in Qt code. What
> consistent of all of them so if we really want to have a standard mask edit
> control and not something "advanced" using regex-like syntax I proposed, it
> might be not such a bad idea to copy this syntax (just to be 100% clear,
> I'm speaking about syntax only here, not the code).
I have in head is more ambitious, more featured.
My mask proposal:
# Required digit.
9 Optional digit.
a Optional alpha character.
N Required alphanumeric character (i.e. letter or digit).
n Optional alphanumeric character.
C Required character (any printable).
c Optional character.
X Required hexadecimal character [0-F]
c Optional character.
x Optional hexadecimal character [0-F]
{x} The previous character (one of the above) is taken x times. This
is an "expander" #{3} expands into ###, H{4} expands into HHHH.
> Convert all following characters to upper case.
< Convert all following characters to lower case.
^ Switch off upper/lower case conversion
< Convert all following characters to lower case.
\ Escape the next character.
Note the above specifications are tested using wxIsxxx functions. So
they are locale dependant.
Any other char is a literal. It is shown in the control, but it can
not be edited.
Literals are also used as fields separators.
'|' is a special literal. It's invisible, takes no space, but still
is a fields separator.
Space is not a char (except for C command?). So pressing space-bar in
a required character position does nothing, while in an optional one
moves cursor to next char/field position.
Flags:
L Left alignment
R Right alignment
S String field. Not setting this flag means the field is numeric.
Numeric means that the digits will be joined in each key event. A
string field does not join its characters.
0 Numeric field with padding zeros
Setting S in an IP field would allow '1_2' which is nonsense. But
let's the user decide it.
No setting S for a Name field will join the chars, stripping out all spaces.
Setting R0 changes "__1" into "001"
Setting L0 is dangerous: it will change '12_' into '120'.
When contradictory flags are found, the last is taken:
Setting LR will discards L. The field will be right aligned.
Setting S0 will discard S. The field will be a numeric one.
Setting 0S will discard 0. The field will be a string one.
We can have other mask commands, such as
H Hour. Expands into 9#. Sets R flag. Sets InRange(0, 23) field checker.
T Minute or Second. Expands into 9#. Sets R flag. Sets InRange(0,
59) field checker.
D Day. Expands into 9#. Sets R flag. Sets InRange(1, 31) field checker.
M Month. Means 9# and R. InRange(1,12)
m Month name abbreviation (Jan, Feb, etc). Expands into CCC. But
allows only some values (taken from a choices array).
Y Year. Expands into ####.
y Year. Expands into 99##. So, allows 2-digits year
Regads
Manolo
Vadim Zeitlin
May 31, 2012, 2:50:11 PM5/31/12
to wx-...@googlegroups.com
On Thu, 31 May 2012 19:47:37 +0200 Manolo wrote:
M> My mask proposal:
M>
M> # Required digit.
M> 9 Optional digit.
M> A Required alpha character.
M> a Optional alpha character.
M> N Required alphanumeric character (i.e. letter or digit).
M> n Optional alphanumeric character.
M> C Required character (any printable).
M> c Optional character.
M> X Required hexadecimal character [0-F]
M> x Optional hexadecimal character [0-F]
M> {x} The previous character (one of the above) is taken x times. This
M> is an "expander" #{3} expands into ###, H{4} expands into HHHH.
M> > Convert all following characters to upper case.
M> < Convert all following characters to lower case.
M> ^ Switch off upper/lower case conversion
M> \ Escape the next character.
OK, let's do it like this. This will hopefully make easier for people to
start using it.
M> '|' is a special literal. It's invisible, takes no space, but still
M> is a fields separator.
OK.
M> Space is not a char (except for C command?).
Yes, I think "C" should allow spaces. This is what you'd use for e.g. name
entry (and not "A" or even "N" because of names like e.g. "O'Henry").
M> Flags:
How are flags specified exactly? I.e. how do they appear in the mask? Or
are they given separately?
M> L Left alignment
M> R Right alignment
OK (except that I still don't know how are they specified).
M> S String field. Not setting this flag means the field is numeric.
M> Numeric means that the digits will be joined in each key event. A
M> string field does not join its characters.
I don't understand this. Do you mean that you want to allow disjoint entry
in the field somehow? You say:
M> Setting S in an IP field would allow '1_2' which is nonsense. But
M> let's the user decide it.
But how can you enter "1_2" at all? Initially the control is empty, i.e.
contains "___.___.___.___". When you press "1" you get "__1.___.___.___".
Now when you press "2" you should get "_12.___.___.___". And if instead of
pressing "2" directly you'd press "Right" and then "2" then you'd get
"__1.__2.___.___". But I don't understand how can you possibly get "1_2"?
M> 0 Numeric field with padding zeros
OK.
M> Setting R0 changes "__1" into "001"
M> Setting L0 is dangerous: it will change '12_' into '120'.
This shouldn't be allowed.
M> When contradictory flags are found, the last is taken:
M> Setting LR will discards L. The field will be right aligned.
M> Setting S0 will discard S. The field will be a numeric one.
M> Setting 0S will discard 0. The field will be a string one.
In any case assert should happen warning about problem with the mask.
Regards,
VZ
M> My mask proposal:
M>
M> # Required digit.
M> 9 Optional digit.
M> A Required alpha character.
M> a Optional alpha character.
M> N Required alphanumeric character (i.e. letter or digit).
M> n Optional alphanumeric character.
M> C Required character (any printable).
M> c Optional character.
M> X Required hexadecimal character [0-F]
M> x Optional hexadecimal character [0-F]
M> {x} The previous character (one of the above) is taken x times. This
M> is an "expander" #{3} expands into ###, H{4} expands into HHHH.
M> > Convert all following characters to upper case.
M> < Convert all following characters to lower case.
M> ^ Switch off upper/lower case conversion
M> \ Escape the next character.
OK, let's do it like this. This will hopefully make easier for people to
start using it.
M> '|' is a special literal. It's invisible, takes no space, but still
M> is a fields separator.
OK.
M> Space is not a char (except for C command?).
Yes, I think "C" should allow spaces. This is what you'd use for e.g. name
entry (and not "A" or even "N" because of names like e.g. "O'Henry").
M> Flags:
How are flags specified exactly? I.e. how do they appear in the mask? Or
are they given separately?
M> L Left alignment
M> R Right alignment
OK (except that I still don't know how are they specified).
M> S String field. Not setting this flag means the field is numeric.
M> Numeric means that the digits will be joined in each key event. A
M> string field does not join its characters.
I don't understand this. Do you mean that you want to allow disjoint entry
in the field somehow? You say:
M> Setting S in an IP field would allow '1_2' which is nonsense. But
M> let's the user decide it.
But how can you enter "1_2" at all? Initially the control is empty, i.e.
contains "___.___.___.___". When you press "1" you get "__1.___.___.___".
Now when you press "2" you should get "_12.___.___.___". And if instead of
pressing "2" directly you'd press "Right" and then "2" then you'd get
"__1.__2.___.___". But I don't understand how can you possibly get "1_2"?
M> 0 Numeric field with padding zeros
OK.
M> Setting R0 changes "__1" into "001"
M> Setting L0 is dangerous: it will change '12_' into '120'.
This shouldn't be allowed.
M> When contradictory flags are found, the last is taken:
M> Setting LR will discards L. The field will be right aligned.
M> Setting S0 will discard S. The field will be a numeric one.
M> Setting 0S will discard 0. The field will be a string one.
In any case assert should happen warning about problem with the mask.
Regards,
VZ
Manolo
May 31, 2012, 4:20:57 PM5/31/12
to wx-...@googlegroups.com
> M> Flags:
>
> How are flags specified exactly? I.e. how do they appear in the mask? Or
> are they given separately?
wxMaskedEdit::SetMask(const wxString& mask)
>
> How are flags specified exactly? I.e. how do they appear in the mask? Or
> are they given separately?
wxMaskedEdit::SetFlags(const wxString& flags)
Because there are more things to set (like choices), I gather them all
in a wxMEParams object.
wxMaskedEdit::SetParams(const wxMEParams&)
> But how can you enter "1_2" at all? Initially the control is empty, i.e.
> contains "___.___.___.___". When you press "1" you get "__1.___.___.___".
> Now when you press "2" you should get "_12.___.___.___". And if instead of
> pressing "2" directly you'd press "Right" and then "2" then you'd get
> "__1.__2.___.___". But I don't understand how can you possibly get "1_2"?
"___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
Empty numeric fields, all with left align (nonsense):
"___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
Empty string fields, all with right align:
"___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
Empty string fields, all with left align:
"___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
Other example, with same configuration:
"___.___" Press "1" you get "1__.___" Press "right" then "2" you get "1_2.___"
If I write this last example with alpha chars, it gets clearer:
"___.___" Press "a" you get "a__.___" Press "right" then "b" you get "a_b.___"
The difference between numeric and strings fields is not the
alignment, but that 'numeric' joins the chars, while 'string' type
keeps spaces. "not typed positions' are considered as spaces.
Pressing cursor "right" only moves it to next field for numeric
fields, because there's nothing to its right (either it is currently
at right-most of the field or the rest at right are blanks in a
left-align field).
And also in any case (numeric/string) if the cursor was at right-most
of the field.
Pressing TAB changes to next field. If the cursor was already in the
last field, allow default processing (i.e. next control)
> M> Setting R0 changes "__1" into "001"
> M> Setting L0 is dangerous: it will change '12_' into '120'.
>
> This shouldn't be allowed.
> In any case assert should happen warning about problem with the mask.
false, without any change to current settings.
Same goes for flags.
Regards
Manolo
Vadim Zeitlin
May 31, 2012, 4:36:33 PM5/31/12
to wx-...@googlegroups.com
On Thu, 31 May 2012 22:20:57 +0200 Manolo wrote:
M> > How are flags specified exactly? I.e. how do they appear in the mask? Or
M> > are they given separately?
M> wxMaskedEdit::SetMask(const wxString& mask)
M> wxMaskedEdit::SetFlags(const wxString& flags)
Why do we need to pass the flags as a string? We want to do it for the
mask because it's more visual, but what's the advantage of doing it for the
flags?
I'd just add
void SetAlignment(int field, wxAlignment align);
void SetPadding(wxChar ch = '0');
methods instead.
M> Because there are more things to set (like choices), I gather them all
M> in a wxMEParams object.
M> wxMaskedEdit::SetParams(const wxMEParams&)
Let's leave this aside for now because I don't want to discuss everything
at once but I'd like to have a look at wxMEParams later.
M> > But how can you enter "1_2" at all? Initially the control is empty, i.e.
M> > contains "___.___.___.___". When you press "1" you get "__1.___.___.___".
M> > Now when you press "2" you should get "_12.___.___.___". And if instead of
M> > pressing "2" directly you'd press "Right" and then "2" then you'd get
M> > "__1.__2.___.___". But I don't understand how can you possibly get "1_2"?
M> Empty numeric fields, all with right align (normal case):
M> "___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
M> Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
M>
M> Empty numeric fields, all with left align (nonsense):
M> "___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
M> Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
M>
M> Empty string fields, all with right align:
M> "___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
M> Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
M>
M> Empty string fields, all with left align:
M> "___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
M> Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
Yes, with you so far.
M> Other example, with same configuration:
M> "___.___" Press "1" you get "1__.___" Press "right" then "2" you get "1_2.___"
Err, no. You get "1__.2__", same as with the example just before. Pressing
"right" switches to the next field, there is no way to have disjoint input
like this.
M> If I write this last example with alpha chars, it gets clearer:
M> "___.___" Press "a" you get "a__.___" Press "right" then "b" you get "a_b.___"
No, no difference. It still shouldn't work like this.
I seems quite obvious to me that the behaviour you describe would be both
difficult to implement *and* absolutely useless. So I really, really don't
see why should it be supported. Simply don't allow such situation to arise
and a lot of complications you're trying to solve simply go away.
M> The difference between numeric and strings fields is not the
M> alignment, but that 'numeric' joins the chars, while 'string' type
M> keeps spaces. "not typed positions' are considered as spaces.
Sorry, I still don't understand this. Let's not confuse "unfilled" and
"space". "Space" is just another character, if allowed. It's not different
from "a" or "b" above. So if you do enter "space" then you could get "a b"
in the control but this is its real value, different from nonsensical "a_b"
which shouldn't be allowed at all.
M> Pressing cursor "right" only moves it to next field for numeric
M> fields,
I strongly disagree. It should do it for all fields, there is no
difference.
M> > M> Setting R0 changes "__1" into "001"
M> > M> Setting L0 is dangerous: it will change '12_' into '120'.
M> >
M> > This shouldn't be allowed.
M> IMO, this is is user's decision, at his own risk.
Why? If you know it's useless -- and you do, because have you ever seen
any input field behaving like this? -- why implement it? I'm really getting
desperate here but please let me repeat again: we're striving to implement
the minimally useful and self-consistent set of functionality. Implementing
support for features that we're absolutely sure nobody will ever use is
really not a good idea, please don't do it.
M> > In any case assert should happen warning about problem with the mask.
M> wxASSERT_MSG or wxCHECK_MSG? And setting the mask will then return
M> false, without any change to current settings.
M> Same goes for flags.
Yes, errors in API calls should be detected (whether you use ASSERT or
CHECK is a matter of taste but CHECK is usually better for simple input
parameter validation) and ignored.
Thanks,
VZ
M> > How are flags specified exactly? I.e. how do they appear in the mask? Or
M> > are they given separately?
M> wxMaskedEdit::SetMask(const wxString& mask)
M> wxMaskedEdit::SetFlags(const wxString& flags)
Why do we need to pass the flags as a string? We want to do it for the
mask because it's more visual, but what's the advantage of doing it for the
flags?
I'd just add
void SetAlignment(int field, wxAlignment align);
void SetPadding(wxChar ch = '0');
methods instead.
M> Because there are more things to set (like choices), I gather them all
M> in a wxMEParams object.
M> wxMaskedEdit::SetParams(const wxMEParams&)
Let's leave this aside for now because I don't want to discuss everything
at once but I'd like to have a look at wxMEParams later.
M> > But how can you enter "1_2" at all? Initially the control is empty, i.e.
M> > contains "___.___.___.___". When you press "1" you get "__1.___.___.___".
M> > Now when you press "2" you should get "_12.___.___.___". And if instead of
M> > pressing "2" directly you'd press "Right" and then "2" then you'd get
M> > "__1.__2.___.___". But I don't understand how can you possibly get "1_2"?
M> Empty numeric fields, all with right align (normal case):
M> "___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
M> Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
M>
M> Empty numeric fields, all with left align (nonsense):
M> "___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
M> Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
M>
M> Empty string fields, all with right align:
M> "___.___" Press "1" you get "__1.___" Press "2" you get "_12.___"
M> Press "right" cursor goes to next field, at right. Press "3" you get "_12.__3"
M>
M> Empty string fields, all with left align:
M> "___.___" Press "1" you get "1__.___" Press "2" you get "12_.___"
M> Press "right" cursor goes to next field, at left. Press "3" you get "12_.3__"
Yes, with you so far.
M> Other example, with same configuration:
M> "___.___" Press "1" you get "1__.___" Press "right" then "2" you get "1_2.___"
Err, no. You get "1__.2__", same as with the example just before. Pressing
"right" switches to the next field, there is no way to have disjoint input
like this.
M> If I write this last example with alpha chars, it gets clearer:
M> "___.___" Press "a" you get "a__.___" Press "right" then "b" you get "a_b.___"
No, no difference. It still shouldn't work like this.
I seems quite obvious to me that the behaviour you describe would be both
difficult to implement *and* absolutely useless. So I really, really don't
see why should it be supported. Simply don't allow such situation to arise
and a lot of complications you're trying to solve simply go away.
M> The difference between numeric and strings fields is not the
M> alignment, but that 'numeric' joins the chars, while 'string' type
M> keeps spaces. "not typed positions' are considered as spaces.
Sorry, I still don't understand this. Let's not confuse "unfilled" and
"space". "Space" is just another character, if allowed. It's not different
from "a" or "b" above. So if you do enter "space" then you could get "a b"
in the control but this is its real value, different from nonsensical "a_b"
which shouldn't be allowed at all.
M> Pressing cursor "right" only moves it to next field for numeric
M> fields,
I strongly disagree. It should do it for all fields, there is no
difference.
M> > M> Setting R0 changes "__1" into "001"
M> > M> Setting L0 is dangerous: it will change '12_' into '120'.
M> >
M> > This shouldn't be allowed.
M> IMO, this is is user's decision, at his own risk.
Why? If you know it's useless -- and you do, because have you ever seen
any input field behaving like this? -- why implement it? I'm really getting
desperate here but please let me repeat again: we're striving to implement
the minimally useful and self-consistent set of functionality. Implementing
support for features that we're absolutely sure nobody will ever use is
really not a good idea, please don't do it.
M> > In any case assert should happen warning about problem with the mask.
M> wxASSERT_MSG or wxCHECK_MSG? And setting the mask will then return
M> false, without any change to current settings.
M> Same goes for flags.
Yes, errors in API calls should be detected (whether you use ASSERT or
CHECK is a matter of taste but CHECK is usually better for simple input
parameter validation) and ignored.
Thanks,
VZ
Manolo
May 31, 2012, 6:32:54 PM5/31/12
to wx-...@googlegroups.com
> Why do we need to pass the flags as a string? We want to do it for the
> mask because it's more visual, but what's the advantage of doing it for the
> flags?
>
> I'd just add
>
> void SetAlignment(int field, wxAlignment align);
> void SetPadding(wxChar ch = '0');
>
> methods instead.
You can pass all flags at once in a wxString. I agree it's useless if
> mask because it's more visual, but what's the advantage of doing it for the
> flags?
>
> I'd just add
>
> void SetAlignment(int field, wxAlignment align);
> void SetPadding(wxChar ch = '0');
>
> methods instead.
we have only one flag.
By the way, wxUniChar instead of wxChar?
> I seems quite obvious to me that the behaviour you describe would be both
> difficult to implement *and* absolutely useless. So I really, really don't
> see why should it be supported. Simply don't allow such situation to arise
> and a lot of complications you're trying to solve simply go away.
> M> The difference between numeric and strings fields is not the
> M> alignment, but that 'numeric' joins the chars, while 'string' type
> M> keeps spaces. "not typed positions' are considered as spaces.
>
> Sorry, I still don't understand this. Let's not confuse "unfilled" and
> "space". "Space" is just another character, if allowed. It's not different
> from "a" or "b" above. So if you do enter "space" then you could get "a b"
> in the control but this is its real value, different from nonsensical "a_b"
> which shouldn't be allowed at all.
Perhaps he prefers arrow right instead of pressing space. But he
thinks it's the same, specially if he is seeing a blank as a fillChar.
This can be the case, not only using C command, but also with any
'optional' command.
And we want to allow this untyped space for 'string' fields (e.g.
Name) and avoid it in 'numeric' ones (e.g. Age). If we don't allow it,
what GetFieldValue() should return for a Name field?
The way I'm thinking for avoiding "accept blank as a space" is joining
the chars (which has sense when they are digits).
So, I end having "to join" and "replace untyped with space" fields
behaviors. I call them 'numeric' and 'string' fields.
We can tell if a field is 'numeric' because its mask has only #9 commands.
But letting the user decide the type (with a flag) is IMO more
flexible, featured.
If the mask does not allow spaces (no cC commands), and the user press
"space" nothing happens, as with any other not allowed char, despite
of 'string' flag or 'optional' command.
> M> Pressing cursor "right" only moves it to next field for numeric
> M> fields,
>
> I strongly disagree. It should do it for all fields, there is no
> difference.
> Why? If you know it's useless -- and you do, because have you ever seen
> any input field behaving like this? -- why implement it? I'm really getting
> desperate here but please let me repeat again: we're striving to implement
> the minimally useful and self-consistent set of functionality. Implementing
> support for features that we're absolutely sure nobody will ever use is
> really not a good idea, please don't do it.
I know *very* well that starting with a minimal functionality means
many times that it will be really hard to improve. I prefer to set the
right structure from the very beginning and improve later.
Regards
Manolo
Vadim Zeitlin
May 31, 2012, 6:44:37 PM5/31/12
to wx-...@googlegroups.com
On Fri, 1 Jun 2012 00:32:54 +0200 Manolo wrote:
M> > I'd just add
M> >
M> > void SetAlignment(int field, wxAlignment align);
M> > void SetPadding(wxChar ch = '0');
M> >
M> > methods instead.
M> You can pass all flags at once in a wxString. I agree it's useless if
M> we have only one flag.
It's bad especially if you have many of them as you lose type safety.
I.e. the question about what to do if both left and right alignment are
specified doesn't even arise with SetAlignment() method.
M> By the way, wxUniChar instead of wxChar?
We use wxChar to be compatible with non-Unicode build.
M> > I seems quite obvious to me that the behaviour you describe would be both
M> > difficult to implement and absolutely useless. So I really, really don't
M> > see why should it be supported. Simply don't allow such situation to arise
M> > and a lot of complications you're trying to solve simply go away.
M> Mask combinations may produce many problematic cases at field validation
M> level.
Not sure if I understand this. Do you have any examples?
M> The user can move inside the field also using the cursor or the mouse.
It should be forbidden or, if it's impossible to forbid changing the
cursor position, it should be at the very least forbidden to enter
characters at such inaccessible positions. This is, of course, tricky part
but very important.
M> And we want to allow this untyped space for 'string' fields (e.g.
M> Name) and avoid it in 'numeric' ones (e.g. Age).
Sorry, no, there is no such thing as "untyped space". There is real space
(which I show as " ") and there is space only used as a placeholder because
we must have everything in all position in wxTextCtrl (which I show as "_").
M> If we don't allow it, what GetFieldValue() should return for a Name
M> field?
Any " " spaces are returned as is. Any "_" spaces are not returned. IOW if
you have "Vadim Zeitlin_______" in an entry with "C{20}" mask, then
GetFieldValue() returns "Vadim Zeitlin". What else?
M> The way I'm thinking for avoiding "accept blank as a space" is joining
M> the chars (which has sense when they are digits).
M> So, I end having "to join" and "replace untyped with space" fields
M> behaviors. I call them 'numeric' and 'string' fields.
I might be misunderstanding something but I think you're overcomplicating
things here. I really don't think there is any need to join anything. Just
ensure that the input is always contiguous.
M> > M> Pressing cursor "right" only moves it to next field for numeric
M> > M> fields,
M> >
M> > I strongly disagree. It should do it for all fields, there is no
M> > difference.
M> How then the user jumps over an optional char without getting out of the
M> field?
If there is already a character entered the navigation keys should work
the same as usual, anything else would be very surprising. But if there is
no character then pressing "right" should go to the next field. Again, this
seems pretty obvious to me, am I missing anything?
M> It's more or less the same effort for me doing one way or another. And
M> I know very well that starting with a minimal functionality means
M> many times that it will be really hard to improve. I prefer to set the
M> right structure from the very beginning and improve later.
The right thing to do is definitely not to allow disjoint input in the
control. This is useless (i.e. can't be used for anything the user really
needs), surprising from the UI point of view and I'm willing to bet that
contrary to what you say above it will make the implementation more
difficult. So I really see absolutely no reason to allow this. Now there
could be some implementation problems with constraining the caret, i.e.
preventing putting it in an invalid position, and we should discuss them if
so, but unless this is impossible at all, it should be done and the caret
should be prevented from being positioned at a blank ("_") position in a
field if there is anything in it (i.e. it would still be on a blank when
starting to edit an empty field, of course).
Regards,
VZ
M> > I'd just add
M> >
M> > void SetAlignment(int field, wxAlignment align);
M> > void SetPadding(wxChar ch = '0');
M> >
M> > methods instead.
M> You can pass all flags at once in a wxString. I agree it's useless if
M> we have only one flag.
It's bad especially if you have many of them as you lose type safety.
I.e. the question about what to do if both left and right alignment are
specified doesn't even arise with SetAlignment() method.
M> By the way, wxUniChar instead of wxChar?
We use wxChar to be compatible with non-Unicode build.
M> > I seems quite obvious to me that the behaviour you describe would be both
M> > difficult to implement and absolutely useless. So I really, really don't
M> > see why should it be supported. Simply don't allow such situation to arise
M> > and a lot of complications you're trying to solve simply go away.
M> Mask combinations may produce many problematic cases at field validation
M> level.
Not sure if I understand this. Do you have any examples?
M> The user can move inside the field also using the cursor or the mouse.
It should be forbidden or, if it's impossible to forbid changing the
cursor position, it should be at the very least forbidden to enter
characters at such inaccessible positions. This is, of course, tricky part
but very important.
M> And we want to allow this untyped space for 'string' fields (e.g.
M> Name) and avoid it in 'numeric' ones (e.g. Age).
Sorry, no, there is no such thing as "untyped space". There is real space
(which I show as " ") and there is space only used as a placeholder because
we must have everything in all position in wxTextCtrl (which I show as "_").
M> If we don't allow it, what GetFieldValue() should return for a Name
M> field?
Any " " spaces are returned as is. Any "_" spaces are not returned. IOW if
you have "Vadim Zeitlin_______" in an entry with "C{20}" mask, then
GetFieldValue() returns "Vadim Zeitlin". What else?
M> The way I'm thinking for avoiding "accept blank as a space" is joining
M> the chars (which has sense when they are digits).
M> So, I end having "to join" and "replace untyped with space" fields
M> behaviors. I call them 'numeric' and 'string' fields.
I might be misunderstanding something but I think you're overcomplicating
things here. I really don't think there is any need to join anything. Just
ensure that the input is always contiguous.
M> > M> Pressing cursor "right" only moves it to next field for numeric
M> > M> fields,
M> >
M> > I strongly disagree. It should do it for all fields, there is no
M> > difference.
M> How then the user jumps over an optional char without getting out of the
M> field?
If there is already a character entered the navigation keys should work
the same as usual, anything else would be very surprising. But if there is
no character then pressing "right" should go to the next field. Again, this
seems pretty obvious to me, am I missing anything?
M> It's more or less the same effort for me doing one way or another. And
M> I know very well that starting with a minimal functionality means
M> many times that it will be really hard to improve. I prefer to set the
M> right structure from the very beginning and improve later.
The right thing to do is definitely not to allow disjoint input in the
control. This is useless (i.e. can't be used for anything the user really
needs), surprising from the UI point of view and I'm willing to bet that
contrary to what you say above it will make the implementation more
difficult. So I really see absolutely no reason to allow this. Now there
could be some implementation problems with constraining the caret, i.e.
preventing putting it in an invalid position, and we should discuss them if
so, but unless this is impossible at all, it should be done and the caret
should be prevented from being positioned at a blank ("_") position in a
field if there is anything in it (i.e. it would still be on a blank when
starting to edit an empty field, of course).
Regards,
VZ
Manolo
May 31, 2012, 8:06:47 PM5/31/12
to wx-...@googlegroups.com
> M> You can pass all flags at once in a wxString. I agree it's useless if
> M> we have only one flag.
>
> It's bad especially if you have many of them as you lose type safety.
> I.e. the question about what to do if both left and right alignment are
> specified doesn't even arise with SetAlignment() method.
The same type safety loss as with the mask. I don't see the problem here.
> M> we have only one flag.
>
> It's bad especially if you have many of them as you lose type safety.
> I.e. the question about what to do if both left and right alignment are
> specified doesn't even arise with SetAlignment() method.
> M> By the way, wxUniChar instead of wxChar?
>
> We use wxChar to be compatible with non-Unicode build.
> M> The user can move inside the field also using the cursor or the mouse.
>
> It should be forbidden or, if it's impossible to forbid changing the
> cursor position, it should be at the very least forbidden to enter
> characters at such inaccessible positions. This is, of course, tricky part
> but very important.
>
> M> And we want to allow this untyped space for 'string' fields (e.g.
> M> Name) and avoid it in 'numeric' ones (e.g. Age).
>
> Sorry, no, there is no such thing as "untyped space". There is real space
> (which I show as " ") and there is space only used as a placeholder because
> we must have everything in all position in wxTextCtrl (which I show as "_").
>
> M> If we don't allow it, what GetFieldValue() should return for a Name
> M> field?
>
> Any " " spaces are returned as is. Any "_" spaces are not returned. IOW if
> you have "Vadim Zeitlin_______" in an entry with "C{20}" mask, then
> GetFieldValue() returns "Vadim Zeitlin". What else?
I'll use here '_' as 'untyped' for the example and '|' for the caret,
but in the control the user sees spaces. Mask is a{10} (optional
chars). Alignment is left.
Initially control is empty. The user clicks in its middle.
The caret auto-moves to most-left "|__________"
The user types "Vadim", Control looks like "Vadim|____"
The users presses clicks at any of the "_". But the caret stays close to 'm'
The users presses right cursor. The caret moves to next field.
But if he presses space instead of arrow, then the control is "Vadim |____"
Now, he press "Z", and sees "Vadim Z|___"
So we are forcing him to press space instead of leaving a blank and
continue with the next char in the same field.
Right?
I'm not sure if this is a good, expected, UI.
Caret constraining should work like this:
When the caret would try to go to an unfilled position, find the first
typed position towards its left for a left aligned field, and towards
its right for a right aligned field, and move there. If there's no
filled position, move to the left/right-most position in that field,
according with the alignment flag.
If the caret tries on a filled position, allow it (i.e. do nothing).
Regards
Manolo
Vadim Zeitlin
May 31, 2012, 8:39:38 PM5/31/12
to wx-...@googlegroups.com
On Fri, 1 Jun 2012 02:06:47 +0200 Manolo wrote:
M> > M> You can pass all flags at once in a wxString. I agree it's useless if
M> > M> we have only one flag.
M> >
M> > It's bad especially if you have many of them as you lose type safety.
M> > I.e. the question about what to do if both left and right alignment are
M> > specified doesn't even arise with SetAlignment() method.
M> The same type safety loss as with the mask. I don't see the problem here.
As I said, we use the mask because it's more visual. There is no such
advantage for the flags.
M> I'll use here '_' as 'untyped' for the example and '|' for the caret,
M> but in the control the user sees spaces.
He doesn't see them, spaces are invisible. For the user there is no way to
distinguish between "nothing" and a space and this is how it should be. The
program must maintain the illusion that there is "nothing" there even if we
need to put spaces to make the text control happy.
FWIW I had originally suggested a completely different approach to the
implementation: instead of using a single text control, use one text
control per field and an extra (read-only) one for each separator between
the fields. With this approach we could really have "nothing".
Unfortunately it has other problems, notably selection across multiple
fields risks to be "interesting" to implement.
But independently of the implementation, the UI behaviour should be the
same and it must not be possible to have disjoint input.
M> Mask is a{10} (optional chars). Alignment is left.
M> Initially control is empty. The user clicks in its middle.
M> The caret auto-moves to most-left "|__________"
M> The user types "Vadim", Control looks like "Vadim|____"
M> The users presses clicks at any of the "_". But the caret stays close to 'm'
M> The users presses right cursor. The caret moves to next field.
M> But if he presses space instead of arrow, then the control is "Vadim |____"
M> Now, he press "Z", and sees "Vadim Z|___"
M>
M> So we are forcing him to press space instead of leaving a blank and
M> continue with the next char in the same field.
M> Right?
Yes, absolutely. Just as in the normal wxTextCtrl without any mask.
M> I'm not sure if this is a good, expected, UI.
I can't understand why is it so. Again, this is *exactly* how any normal
text entry zone behaves. Why should this one behave differently?
M> Caret constraining should work like this:
...snip...
Yes, and I suspect it's not going to be trivial to implement this but,
again, it's another issue. In the worst case you could always forcibly
reset the caret to the correct position in EVT_IDLE although I hope we
can find a better way.
Regards,
VZ
M> > M> You can pass all flags at once in a wxString. I agree it's useless if
M> > M> we have only one flag.
M> >
M> > It's bad especially if you have many of them as you lose type safety.
M> > I.e. the question about what to do if both left and right alignment are
M> > specified doesn't even arise with SetAlignment() method.
M> The same type safety loss as with the mask. I don't see the problem here.
As I said, we use the mask because it's more visual. There is no such
advantage for the flags.
M> I'll use here '_' as 'untyped' for the example and '|' for the caret,
M> but in the control the user sees spaces.
He doesn't see them, spaces are invisible. For the user there is no way to
distinguish between "nothing" and a space and this is how it should be. The
program must maintain the illusion that there is "nothing" there even if we
need to put spaces to make the text control happy.
FWIW I had originally suggested a completely different approach to the
implementation: instead of using a single text control, use one text
control per field and an extra (read-only) one for each separator between
the fields. With this approach we could really have "nothing".
Unfortunately it has other problems, notably selection across multiple
fields risks to be "interesting" to implement.
But independently of the implementation, the UI behaviour should be the
same and it must not be possible to have disjoint input.
M> Mask is a{10} (optional chars). Alignment is left.
M> Initially control is empty. The user clicks in its middle.
M> The caret auto-moves to most-left "|__________"
M> The user types "Vadim", Control looks like "Vadim|____"
M> The users presses clicks at any of the "_". But the caret stays close to 'm'
M> The users presses right cursor. The caret moves to next field.
M> But if he presses space instead of arrow, then the control is "Vadim |____"
M> Now, he press "Z", and sees "Vadim Z|___"
M>
M> So we are forcing him to press space instead of leaving a blank and
M> continue with the next char in the same field.
M> Right?
Yes, absolutely. Just as in the normal wxTextCtrl without any mask.
M> I'm not sure if this is a good, expected, UI.
I can't understand why is it so. Again, this is *exactly* how any normal
text entry zone behaves. Why should this one behave differently?
M> Caret constraining should work like this:
...snip...
Yes, and I suspect it's not going to be trivial to implement this but,
again, it's another issue. In the worst case you could always forcibly
reset the caret to the correct position in EVT_IDLE although I hope we
can find a better way.
Regards,
VZ
Manolo
Jun 1, 2012, 5:53:04 AM6/1/12
to wx-...@googlegroups.com
> FWIW I had originally suggested a completely different approach to the
> implementation: instead of using a single text control, use one text
> control per field and an extra (read-only) one for each separator between
> the fields. With this approach we could really have "nothing".
> Unfortunately it has other problems, notably selection across multiple
> fields risks to be "interesting" to implement.
The first thing I asked: is this a composite control? I understood it was not.
> implementation: instead of using a single text control, use one text
> control per field and an extra (read-only) one for each separator between
> the fields. With this approach we could really have "nothing".
> Unfortunately it has other problems, notably selection across multiple
> fields risks to be "interesting" to implement.
> M> So we are forcing him to press space instead of leaving a blank and
> M> continue with the next char in the same field.
> M> Right?
>
> Yes, absolutely. Just as in the normal wxTextCtrl without any mask.
Regards
Manolo
Vadim Zeitlin
Jun 1, 2012, 7:05:46 AM6/1/12
to wx-...@googlegroups.com
On Fri, 1 Jun 2012 11:53:04 +0200 Manolo wrote:
M> > FWIW I had originally suggested a completely different approach to the
M> > implementation: instead of using a single text control, use one text
M> > control per field and an extra (read-only) one for each separator between
M> > the fields. With this approach we could really have "nothing".
M> > Unfortunately it has other problems, notably selection across multiple
M> > fields risks to be "interesting" to implement.
M> The first thing I asked: is this a composite control? I understood it was not.
I think it's going to be difficult to implement it as a composite control
but, of course, there are going to be some problems with doing it with a
single control too so I might be wrong...
M> > M> So we are forcing him to press space instead of leaving a blank and
M> > M> continue with the next char in the same field.
M> > M> Right?
M> >
M> > Yes, absolutely. Just as in the normal wxTextCtrl without any mask.
M> I'll implement this behaviour.
Thanks!
VZ
M> > FWIW I had originally suggested a completely different approach to the
M> > implementation: instead of using a single text control, use one text
M> > control per field and an extra (read-only) one for each separator between
M> > the fields. With this approach we could really have "nothing".
M> > Unfortunately it has other problems, notably selection across multiple
M> > fields risks to be "interesting" to implement.
M> The first thing I asked: is this a composite control? I understood it was not.
I think it's going to be difficult to implement it as a composite control
but, of course, there are going to be some problems with doing it with a
single control too so I might be wrong...
M> > M> So we are forcing him to press space instead of leaving a blank and
M> > M> continue with the next char in the same field.
M> > M> Right?
M> >
M> > Yes, absolutely. Just as in the normal wxTextCtrl without any mask.
M> I'll implement this behaviour.
Thanks!
VZ
Reply all
Reply to author
Forward
0 new messages