Strangely - Not a question

[J-G]

Whenever I post here I'm usually seeking answers to issues that elude me but Today I have had a small victory over that ways that Lazarus/FPC endeavours to thwart me without the need to interupt the very busy lives that contributors here have 

The project involves entering a HEX number into a TEdit and since there is no Property 'HexOnly' (as there is a NumbersOnly (with limited usefulness)) and I wish to trap 'Invalid Key Strokes' to display meaningful information, I set about writing a 'Key Validation' routine. Nothing really taxing once you get your head around the difference between 'KeyNumber' and 'ScanCode' but I had one 'silly' irritation.

When an invalid character was used, I could trap it, determine what it was, show the user what key was unacceptable and remove it from the 'string', All well and good BUT the editing position within the string was always set at the start - rather than the position that the invalid key was typed.

At this point I didn't even know what 'property' I needed to modify to set the 'Cursor' position. A little research and I discovered 'CaretPos' and sure enough I soon found that as a 'Property' of the TEdit. Now I could store this property at the start of the validation and retrieve it at the end  - - -  'simples' - - -  wrong!

Yes, I could assign it to a var at the start - though initially I declared that as 'Byte' when in fact it's a 'TPoint' but that was a minor issue - and restore it at the end,  but the result was that the position was always one character to the right of the original ???

Ah - I thought - take 1 off the TEdit.CaretPos 'X'  - - -   again wrong, compiler says 'not allowed'  -  Next attempt, modify the Var (which of course is also a TPoint but not a 'property' of the TEdit).  That is allowed, so, assign the Var, take one off the 'X' property then at the end of the proc. assign the TEdit.CaretPos to the Var  - - -  fully acceptable.

I said at the start that I wasn't interupting your busy lives but if you've read this far of course I have  sorry - I hope that it is minimal  -  but this tale may assist someone else who needs to know where the cursor actually is (for whatever reason!)  - and it's always good to share a 'success' 🤣

[cdbc]

Hi J-G
Ahh, back from holiday... \o/
?) You do know that 'CaretPos' deals in 'CodePoint's -- -NOT- in chars/bytes ?!?
Might bite you on the ass, with regards to unicode-text / UTF8-text 
Just saying...
Regards Benny

[olatov]

I remember using OnKeyPress event for stuff like this - you simply filter keys, resetting invalid ones to #0, that should not interfere with the position of the cursor. It will not save you from pasting invalid chars using a mouse, though.

Code: Pascal  [Select][+][-]

1. procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: char);
2. begin
3.   case Key of
4.     '0'..'9', 'a'..'f', 'A'..'F', #8:   { #8: Backspace }
5.       ErrorLabel.Caption := 'OK';
6.   else
7.     ErrorLabel.Caption := 'Invalid character - "' + Key + '"';
8.     Key := #0;
9.   end;
10. end;  

[Dankan1890]

TMaskEdit ?

[J-G]

TMaskEdit ?

I've tried that in the past and found it a PITA  -  far too restrictive.

[J-G]

Hi J-G
Ahh, back from holiday... \o/
?) You do know that 'CaretPos' deals in 'CodePoint's -- -NOT- in chars/bytes ?!?
Might bite you on the ass, with regards to unicode-text / UTF8-text 
Just saying...
Regards Benny

Hi Benny - hope you had a pleasant one 

An interesting point and a very valid observation. In my use case though I'm only dealing with simple Keyboard entry - though I could forsee a user trying the [Alt][Keypad] aproach - but I'm really looking to trap "typo's" where (say) a 'Y' key gets pressed rather than a '6' or '7' - but I have handled all potential single key-strokes  -  I may look at trapping the [Alt] Key as well,  though I suspect  . . . . . .

[Later]   
I've now trapped the potential [Alt] KeyPad entry     Better to cover all bases !
I was thinking that the [Alt] key might be trapped by some 'Windows' system call before a programmer could gain access. - in fact that may be the case but once a NumPad key has been pressed then it can be tested using the if Shift = [ssAlt] then construct.

There can never be a UNICODE entry in this particular use - essentially I suppose what I'm doing is creating what was 'ReadKey' under a DOS environment. It's just taken me some 15+ years to get around to it 🤣

The project doesn't expect the user to 'Enter' a UNICODE ref. it takes Decimal. Hex or Binary input and evaluates a Unicode value.

[ASerge]

A little research and I discovered 'CaretPos' and sure enough I soon found that as a 'Property' of the TEdit.

For TEdit (not TMemo), it’s better to use SelStart. It’s simple:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   Edit1.AutoSelect := False;
4.   Edit1.Text := 'wrOong char';
5.   Edit1.SelStart := 2;
6.   Edit1.SelLength := 1;
7.   ActiveControl := Edit1;
8. end;
9.  
10. procedure TForm1.Button2Click(Sender: TObject);
11. begin
12.   Edit1.SelText := '';
13.   ActiveControl := Edit1;
14. end;

[Curt Carpenter]

Ah that wonderful endorphin rush when you finally crack and solve a problem after a day or two of frustration!

[J-G]

Ah that wonderful endorphin rush when you finally crack and solve a problem after a day or two of frustration!

It's 'Palpable' 😂  -  mine are usually longer than 'a day or two' !

[Bart]

TMaskEdit ?

I've tried that in the past and found it a PITA  -  far too restrictive.

Yes, but you can set an EditMask so that it only ever accepts Hex characters (upper- or lowercase as you wish), and you cannot even paste non-Hex into it.
You may find that too restrictive, but it seems it does exactly what you say you want?

Bart