Re: [fpc-pascal] Any chance to add the TStringBuilder to FCL?

[Jürgen Hestermann]

Am 2016-04-16 um 19:39 schrieb Dmitry Boyarintsev:
> The problem is with using "unsigned" as an index (rather than zero- vs one- 
based arrays)
> Take a while loop as an example, where index can change multiple times.
> Current solution:
> while i>=0 do
>   if cond then dec(i);
>   dec(i);
> end;
> Unsigned index solution
> while i>=0 do
>   if cond then if i>0 then dec(i);
>   if i>0 then dec(i);
> end;
> Without these checks, unsigned integer would loop over to $ and will 
continue.

That looks to my like an very artifical example.
I never came over a loop where I (conditionally)
decremented the index twice.
But of course, if you have such a case, then you
can only use signed intergers.

But in all the following cases I could used an unsigned
integer (when having 1-based arrays):

1.) for i := low(array) to high(array)

2.) repeat or while loops where the index is in- or
decremented by a maximum of 1 (which IMO is the case
in 99,9% of all such loops).

3.) When storing an array index into a variable for later use.

Nevertheless, using unsigned integers was only one aspect
of 1-based arrays. The main one for me was, that it is
much more intuitive and therefore less error prone.
I already often had errors when calculating indices for 0-based arrays.

And why was a directive implemented to use 0-based indices
even for strings but none for 1-based indices in dynamic arrays?
IMO the latter would be much more desired.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TMaskUtils.ValidateInput function: how is it supposed to behave?

[Bart]

Hi,

I cannot find any documentation about TMaskUtils.ValidateInput
function (unit MaskUtils).
AFAICS Delphi does not have such a class?
(ref: http://docwiki.embarcadero.com/Libraries/XE6/en/System.MaskUtils)

There are some bugreports about this unit in Mantis which got me interested.

See the attached demo program.

It outputs:
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\maskutils>mutest
Mask : "###"
Value: "ABCD"
VI   : "   "   (Shouldn't this fail?)

Mask : "999"
Value: "ABCD"
VI   : "   "   (Shouldn't this fail?)

Mask : "000"
Value: "ABCD"
ValidateInput Failed

Mask : "LLL"
Value: "1234"
ValidateInput Failed

Mask : "lll"
Value: "1234"
VI   : "   "   (Shouldn't this fail?)

Mask : "AAA"
Value: "[{|/"
ValidateInput Failed

Mask : "aaa"
Value: "[{|/"
VI   : "   "   (Shouldn't this fail?)

I am the maintainer of the Lazarus MaskEdit unit.
I find the results rather confusing and inconsistent with
Lazarus/Delphi MaskEdit behaviour.

Note:
When the mask contains mask-characters that mean "value must be of
type XYZ, but not required" the ValidateInput accepts any input.
The same characters in MaskEdit (both Lazarus and Delphi) interpret
this as: "if you put anything in that place it must be of type XYZ,
but you may leave this place empty (e.g. a blank)".
Basically ValidateInput now treats '#', '9', 'l' and 'a' as if it were
'c' (any character allowed here). This seems wrong to me.

However, since the function lacks any documentation one can argue that
current behaviour is correct.

To me the (IMO more logical) behaviour of the ValidateInput function
could be described as the result of these actions in a LCL/VCL
program:

- have a MaskEdit1: TMaskEdit
- do MaskEdit1.EditMask := Mask
- do MaskEdit1.Text := Value
- do MaskEdit1.ValidateEdit
- if no exception is raised then the result will be
MaskEdit1.EditText, but with all "SpaceChar" repkaced by #32.

I.o.w. the function shall raise an exception it Value (after appllying
Mask to it) does NOT match the Mask.

So, is it a bug?
If so, I'll open a ticket in Mantis for it (and the discussion should
then move there).

Bart


mutest.lpr
Description: Binary data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal