Recent

Author Topic: [SOLVED] Is this a bug in TMaskEdit?  (Read 12793 times)

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #15 on: March 06, 2021, 11:10:32 pm »
using a MASK := 000-000-0000;0;_;
hitting the backspace causes the first initial input to land on the second digit.
I cannot reporduce that.

Also there seems to be something wrong with displaying unwanted tail items in the EDIT, like the ";" etc

Indeed that is not Delphi compatible.

This is what I concluded from (I think) Delphi3 help files:

A value for SpaceChar is only valid if also a value for MaskSave is specified
(as by Delphi specifications), so Mask must be at least 4 characters
These must be the last 2 or 4 characters of EditMask (and there must not be
an escape character in front!)

So if a mask ends in ;0;_ then SpaceChar will be _
If a mask ends in ;0; the behaviour is undefined IMO.

It seems like Delphi (7) simply ignores if the last ; if a mask ends in ;
e.g. 'ccc;' is treated as 'ccc' (which is the same as 'ccc;1;_')
'ccc;0;' is treated as 'ccc;0;_'
But then 'ccc;0;_;' the first ; is treated as a maskliteral and the last ; is discarded, the 0 is treated as MaskNoSave
And 'ccc;X;_;' the X is not treated as "not MaskNoSave" (normally anything other than 0 is treated as if it were 1 in that part of the mask).

All in all, it is utterly inconsistent.
At least I cannot mak head or tails of it.

In or implementation the rules are relatively simple:
If the mask ends in ';' + SomeAnsiChar + ';' + SomeAnsiChar and there is no '\' in front of the first ';' then you have defined a value for SpaceChar and wether or not the mask is included when you retrieve the Text
You can omit the last 2 (SomeAnsiChar + ';') and then SpaceChar will be '_' by default.

If you do anything else, all of the ';' will be treated as a mask lilteral.

So unless you can come up with a consistent algorithm how to treat a mask that ends in a ';', I'm not willing to change it ATM.

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #16 on: March 06, 2021, 11:15:36 pm »
The only issue I have with it is it does not have an OnError event, nor does Delphi last time I checked so its kind of hard to capture the error and make a choice on what to do with it, ignore the error and fill in some defaults, Exit with an message box or somehow force it to about its editing back to the original text that was there upon entry..

As I sated before: you can do that in Application.OnException.
There you can inspect the value of either Text or EditText and decide what you want to do.
My MaskEdit test suite uses this:

Code: Pascal  [Select][+][-]
  1. procedure TForm1.AppException(Sender: TObject; E: Exception);
  2. begin
  3.   if (E is EDBEditError) then
  4.   begin
  5.     ShowMessage(E.Message);
  6.     if (Sender is TCustomMaskEdit) then TCustomMaskEdit(Sender).SetFocus;
  7.   end
  8.   else
  9.     Application.ShowException(E);
  10. end;

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #17 on: March 07, 2021, 10:18:08 pm »
Seriously you can't see the bug in the MASK ?

You're right.

Fixed in r64767.
Thanks for noticing.

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #18 on: March 08, 2021, 10:25:48 pm »
Seems to work with both 0000 and !(0000), I am sure the others will appreciate you

It's kind of my baby ...

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #19 on: March 09, 2021, 07:11:30 pm »
The only issue I have with it is it does not have an OnError event...

I implemented that in r64773.
It is experimental and absolutely not Delphi compatible.
As such, the option is not published, nor is the corresponding event.
You'll have to assign it in code.

Bart
« Last Edit: March 09, 2021, 07:13:44 pm by Bart »

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #20 on: March 10, 2021, 09:35:50 am »
That would not make much sense to me.
In the event you can do whatever you would like to do: show an errormessage, silently re-focus the maskedit, correct the text in the control, ask the user to pay you in bitcoins, format his harddrive, or do just nothing (in effect just ignoring the validation)...
Infinite possibilities.

A "var Accept" parameter would make sense if, when user does not accept, it would automatically reset the control to some previous state (what state would that be then?).
I'll investigate if that is possible at all.

I thought of adding a paramter indicating at what index in the control the first "mismatch" was, but implementing that would need yet another private field, which feels a bit hackish.
Even nicer might be to also indicate what the reason for the validation error was. Something like: at index 2: expected: number, found: blank. But that feels like overkill. This information then would also have o be propagated if the Exception method is used, which would be Delphi incompatible as well.

In the end, the reason for implementing this solution, only ever was to avoid having to use exceptions (that can only be handled in a OnException handler).

Bart

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: [SOLVED] Is this a bug in TMaskEdit?
« Reply #21 on: March 10, 2021, 09:54:20 am »
OK, while it is technically possible to implement a "var Accept" or similar parameter, the question then would be what to do if Accept is False.
Reset would be a possible solution, but Clear is possible too.
Mind you, that the TMaskEdit instance itself would then have to decide what the proper action would be.
If I implement it as "Reset if Accept is False", then other users can argue or request that "Clear if Accept is False" or "Set Text to a user defined Text if Accept is False" (like e.g. TFileNameEdit does) suits their applicartion/use case better.

Also: does "Accept = True" make much sense? If so, then why would you use a TMaskEdit in the first place?

So, for the time being, I don't think I will implement it this way.

Bart

 

TinyPortal © 2005-2018