Hi,

I have implemented a NumbersOnly property for TCustomEdit in r43678. Currently it only does something on Win32/Win64 and WinCE (the latter one I am unable to test), since these widgetsets have native support for this feature.

It is only available in trunk, and I don't think it'll be in 1.2 release (since it's a new feature sice we released 1.2RC1). ATM it is only published for TEdit (for all other descendants it's public).

I don't know if GTK2, Carbon, Cocoa and QT can support this.

Please test and report bugs in the bugtracker.

Bart

Others can emulate it in keydown and set text, besides that that Qt supports (QLineEdit)
such scenario by using QValidator (QIntValidator) for input evaluation.

z.

Hmm, can we use this to implement NumbersOnly in the QT WS code?

Bart

Yes, but why we should use any widgetset to implement such property ? Isn't keyDown/SetText enough to implement it in lcl ?

z.

Bart wrote

I have implemented a NumbersOnly property for TCustomEdit in r43678.

Confused... Why not just use a MaskEdit widget? Or doesn't LCL have a TMaskedEdit component?
Regards,
Graeme

Because Maskedit always does a lot more than just limiting your entry to numbers. Alignment, adding spaces whatnot. Usually in totally unnatural ways

I never liked a maskedit.

Michael.

Michael Van Canneyt wrote

Because Maskedit always does a lot more than just limiting your entry to numbers. Alignment, adding spaces whatnot. Usually in totally unnatural ways

OK, fair enough, but all those can be configured too.

Anyway, back in my VCL and LCL days I used to simply hook a generic OnKeyPress event to TEdit and it automatically limited the text box to numeric data only. The event handler was something like 2-3 lines of code. I could find it if somebody was really interested - oh, and it worked on all platforms too.

Regards,
- Graeme -

Mailing Lists wrote

Confused... Why not just use a MaskEdit widget?

Because a masked MaskEdit also limits the number of digits one can enter. And it doesn't look as nice as a simple TEdit.

Personally I would go for a T(Float)SpinEdit rather than a MaskEdit.

Or doesn't LCL have a TMaskedEdit component?

Yes, I rewrote major parts of it in the past, and now maintain it.

Bart

Michael Van Canneyt wrote

I never liked a maskedit.

Well, ages ago (as it seems) we didn't have a decent MaskEdit. I needed it and so rewrote major parts of it.
And tried to get rid of some illogical features that the Borland guys introduced.

After I had done that, I realized that Lazarus had a better component for what I wanted to achieve in the first place... (I came from Delphi 3, where such a component was not avaialable at all.)

From TMaskEdit I derived a TTimeEdit control, which I happily use inn

some of my apps.

An edit control that controls input based on a regex, and looking like a simple TEdit, might be a nice feature to have.

Bart

We've all done that.
Just deny all Keys except ['0..'9',#8] in OnKeyPress. But it doesn't take care of pasting.
(And it doesn't display the nice balloon message when you try to enter/paste invalid data.)

You do not need to like it, you do not need to use it. Feel free to use the more generic solution.
Personally I prefer a TSpinEdit and TFloatSpinEdit (the NumbersOnly only allows positive integers, you cannot even type a "-" in it, let alone a decimalseparator.

It was a feature request (and often requested), AND Delphi has this property also.
And it is easy to implement.
The only reservation I had is that is not cross platform.

But if it is perceived as an unneccesary feauture that should never have been in Lazarus in the first place, I'll be happy to remove it again.

Bart

An edit control that controls input based on a regex, and looking like a simple TEdit, might be a nice feature to have.

I found general masking problems while entering (incomplete) input, and while editing the previous input. Where should the cursor be moved, i.e. which (first) character doesn't match the specification?

IMO the problem boils down to an fault-tolerant parser, that allows to hilite wrong parts of some input, but does not prevent changes in other places, which finally *may* lead to a correct input. Not so obvious with only numerical input, but a big problem with e.g. phone numbers with embedded fixed characters.

The control should allow to hilite individual wrong characters, what's beyond the capabilities of simple edit controls (requires RTF or similar formatting features).

DoDi

Hans-Peter Diettrich wrote

I found general masking problems while entering (incomplete) input, and while editing the previous input. Where should the cursor be moved, i.e. which (first) character doesn't match the specification?

You lost me here.
Which component are you describing here?

Bart

I am all for this, but I would implement a property RegEx in TEdit itself. Not yet another control.

Michael.

Bart wrote

An edit control that controls input based on a regex, and looking like a simple TEdit, might be a nice feature to have.

Much better idea, but as Michael pointed out, you probably don't need another control for that. Take a look at Qt for a nice example (if I'm not mistaken). They allow you to set an input mask for a standard textedit control. That input mask (validator) may be regex too. This is a lot more powerful that VCL/LCL's MaskEdit or a specialised SpinEdit etc.

But if you guys are anal about "delphi compatibility" like the FPC developers, then that is probably not an option for you.

Regards,
- Graeme -

Graeme Geldenhuys wrote

another control for that. Take a look at Qt for a nice example (if I'm not mistaken).

Here is what I was talking about...

http://ynonperek.com/course/qt/validation.html

Regards,
- Graeme -

A new one, that overcomes the problems of the existing ones.

DoDi

Graeme Geldenhuys wrote

But if you guys are anal about "delphi compatibility" like the FPC developers, then that is probably not an option for you.

AFAIK there is no objection to extent our LCL controls beyound Delphi capabilities.
The compatibility must be tha we can compile Delphi code, the other way around isn't required,

Bart

Bart wrote

The compatibility must be that we can compile Delphi code, the other way around isn't required,

Okay, that's a good stance compared to the Free Pascal team.

Regards,
- Graeme -

Eh ?

I don't see how the stance of the FPC team differs ?

There are extensions to basic routines or even extra routines and units in the RTL as well ?

Michael.

I guess he means: The Delphi mode should be back-to-delphi compatible.

Note: A discussion about FPC/Delphi compatibility is better held on the fpc lists. Thanks.

Mattias

The Lazarus team seems to want to be able to convert and compile Delphi code. Only in one direction.

The Free Pascal team wants Delphi compatibility in both directions. Moving from Delphi to FPC, and then still keep the ability to move back to Delphi. The second part is ridiculous as far as I'm concerned - it limits FPC too much in what it can do, change or improve.

Regards,
- Graeme -

+1

2014/1/13 Graeme Geldenhuys

No, this is not correct.

The compiler's Delphi mode does attempts to emulate the compiler as much as possible, yes. But other than that, we strive for the same thing as Lazarus: Delphi code should compile.

Michael.

Am 13.01.2014 20:59 schrieb "Graeme Geldenhuys" <

Then we wouldn't have mode ObjFPC and the other non-Delphi modes.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140113/f6a73f71/attachment.html>

Wrong.

It should be possible to maintain components for both Delphi and FPC at the same time yes, with minimization of ifdefs.

The trouble is that anything else is a lot more difficult than most people think.

Both making _meaningful_ extensions and having them not compromise that compatibility in a practical way.

Exceptions that require codechanges pile on over time, making the question of compatibility academical.

Please do not hijack this thread.
It is about NumbersOnly property, not about general fpc/lazarus <-> delphi comaptibility.
Use another thread for that.

Bart

Bart wrote

Personally I would go for a T(Float)SpinEdit rather than a MaskEdit.

Yes, that's the easiest way to control range-bound number input. It just lacks an option to get rid of those spacious up/down elements. Any chance to get that done?

Frank

A TSpinEdit without spins elements?
Why not use TEdit?

Mattias

2014/1/22 Mattias Gaertner

Frank, are you complaining about the SIZE of the arrows? Maybe you need smaller ones (or a property to set their size). -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20140122/57681f84/attachment.html>

You're right, that sounds weird. But why extend a TEdit and add Min-/Max-/Value properties including all the logistics behind them to get what the Float-/SpinEdit controls already offer?

Frank, are you complaining about the SIZE of the arrows? Maybe you need smaller ones (or a property to set their size).

Sometimes I'd like to have them completely removed, not in the least to gain space.

Think of a 2-dimensional matrix of numbers, which have to be observed though hardly changed, where it may be disturbing to see all those values separated by spacious arrows.

And for what reason do I need gradual ups and downs when entering a TCP port number, where there's no logical neighborhood between most of them and keyboard usage is the only sufficient way to change a value (SMTP ports: ..25..465..587..65535)? In those frequent cases offering arrows looks like a joke.

A single boolean ShowArrows property or, following your idea, an integer ArrowsWidth property with '0' removing it completely would solve that problem preserving a coherent codebase.

Frank

You're right, that sounds weird. But why extend a TEdit and add Min-/Max-/Value properties including all the logistics behind them to get what the Float-/SpinEdit controls already offer?

Frank, are you complaining about the SIZE of the arrows? Maybe you need smaller ones (or a property to set their size).

Sometimes I'd like to have them completely removed, not least to gain space.

Think of a 2-dimensional matrix of numbers, which have to be observed though hardly changed, where it may be disturbing to see all those values separated by spacious arrows.

And for what reason do I need gradual ups and downs when entering a TCP port number, where there's no logical neighborhood between most of them and keyboard usage is the only sufficient way to change a value (SMTP ports: ..25..465..587..65535)? In those frequent cases offering arrows looks like a joke.

A single boolean ShowArrows property or, following your idea, an integer ArrowsWidth property with '0' removing it completely would solve that problem preserving a coherent codebase.

Frank

It's not "just like that". What widgetsets supports hiding arrows ? Only windows or none ? On the other side we don't have ability to create special TEdit + Arrows which can be hidden (arrows must be child of TEdit), and that's probably possible only with qt and maybe with win32 (gtk2/carbon does not support such things).
IMO, only solution atm is to create your own class eg. TNumberEdit and handle input events so you can discard anything except numbers.

z.

You're right. The arrow elements aren't allowed to be there in the first place. OTOH I don't see an urgent need to support changing visibility of the spinner part during runtime. ...

IMO, only solution atm is to create your own class eg. TNumberEdit and handle input events so you can discard anything except numbers.

... So why not introduce a TCustomEdit based intermediary TCustomFloatEdit class including the SpinEdit's Min-/Max-/Value properties with the related logistics, from which then the TCustomFloatSpinEdit class with the spinner part added derives? That separation would prevent widgetset modifications as well as redundant number filtering code.

Frank