Recent

Author Topic: TEdit.PasswordChar should be of type WideChar  (Read 7578 times)

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
TEdit.PasswordChar should be of type WideChar
« on: January 28, 2022, 09:23:03 pm »
I'd suggest to change Char type to WideChar. This will allow ppl to apply 'nice unicode thick dot' characters or even 'square' chars.
The LCL change will be easy.
Widgetsets will need only small changes.
Can I prepare the patches?

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: TEdit.PasswordChar should be of type WideChar
« Reply #1 on: January 28, 2022, 11:15:16 pm »
I'd suggest to change Char type to WideChar.
Please no.  It's really nice that char is char, not something else.  This may not be important when writing normal applications but, when inspecting strings that are outside one's program, it is crucial that a char be a char and not anything else.

ETA:

I just realized that you are suggesting the change to be local to TEdit.PasswordChar, I don't have anything against that. :)
« Last Edit: January 28, 2022, 11:17:50 pm by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TEdit.PasswordChar should be of type WideChar
« Reply #2 on: January 28, 2022, 11:18:38 pm »
Why is it critical, that this is Char? What will your application loose?

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: TEdit.PasswordChar should be of type WideChar
« Reply #3 on: January 29, 2022, 12:06:35 am »
Why is it critical, that this is Char? What will your application loose?
For instance, when trapping one of more APIs in some DLL - a system DLL or some application's DLL - all the exported (and imported) names are in char not widechar.  That's the most common instance but, in spite of what MS says, there are a fair number of strings/identifiers in the system that are char, not widechar.

Unicode is fine and useful for user interfaces and other things that may need to be translated to other languages but, at the system level it's crucial to be able to use char - most likely because the PE format is char based not Unicode based.
« Last Edit: January 29, 2022, 12:09:37 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Zoran

  • Hero Member
  • *****
  • Posts: 1829
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: TEdit.PasswordChar should be of type WideChar
« Reply #4 on: January 29, 2022, 01:46:32 am »
Any unicode character should be allowed, widechar is not the solution.
LCL uses UTF-8, so it should be utf-8 encoded (so, a string). Some program control should exist in property setter, which checks that only strings which represent one utf8 encoded character are allowed -- Utf8Length must return 1.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: TEdit.PasswordChar should be of type WideChar
« Reply #5 on: January 29, 2022, 08:22:27 am »
Why is it critical, that this is Char? What will your application loose?
For instance, when trapping one of more APIs in some DLL - a system DLL or some application's DLL - all the exported (and imported) names are in char not widechar.  That's the most common instance but, in spite of what MS says, there are a fair number of strings/identifiers in the system that are char, not widechar.

Unicode is fine and useful for user interfaces and other things that may need to be translated to other languages but, at the system level it's crucial to be able to use char - most likely because the PE format is char based not Unicode based.

Mis-use of char detected, what you mean is byte sized AnsiChar? Depending on mode you confuse people by insisting "char". That is actually C'ism.
(I know it is not ideal, but Freepascal allows for de-contamination of such folly)
Specialize a type, not a var.

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: TEdit.PasswordChar should be of type WideChar
« Reply #6 on: January 29, 2022, 09:15:29 am »
Any unicode character should be allowed, widechar is not the solution.
LCL uses UTF-8, so it should be utf-8 encoded (so, a string). Some program control should exist in property setter, which checks that only strings which represent one utf8 encoded character are allowed -- Utf8Length must return 1.

Why limit UTF8Length to 1?

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: TEdit.PasswordChar should be of type WideChar
« Reply #7 on: January 29, 2022, 09:57:53 am »
Indeed, can be 4.
Specialize a type, not a var.

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: TEdit.PasswordChar should be of type WideChar
« Reply #8 on: January 29, 2022, 10:23:33 am »
The API actually accepts PassWordChar to be (when translated to UTF8) 4 codepoints wide?
(Or do the 4 codepoints then make up one grapheem?)

Bart

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: TEdit.PasswordChar should be of type WideChar
« Reply #9 on: January 29, 2022, 10:29:39 am »
Mis-use of char detected, what you mean is byte sized AnsiChar? Depending on mode you confuse people by insisting "char". That is actually C'ism.
(I know it is not ideal, but Freepascal allows for de-contamination of such folly)
No Thaddy, it's a history-ism.  char has been the single byte character type for I'm not sure how many decades but definitely a good bit more than the yuppie ansichar and widechar.

One of the things I like best about Freepascal is that when I declare a variable to be of type "char" it's actually of type "char" ...Wow!!  Amazing, they still make compilers that parse by the rules.

Thank God for breathable air, underwear, women and the single byte character type.



(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: TEdit.PasswordChar should be of type WideChar
« Reply #10 on: January 29, 2022, 04:31:27 pm »
The API actually accepts PassWordChar to be (when translated to UTF8) 4 codepoints wide?
4 code points is a lot. May be code units? For reference, in UTF8 encoding, the code unit is a byte, and the code point is up to 4 bytes.

But WinAPI, as far as I know, accepts only one codeunit.

AlexTP

  • Hero Member
  • *****
  • Posts: 2384
    • UVviewsoft
Re: TEdit.PasswordChar should be of type WideChar
« Reply #11 on: January 29, 2022, 04:32:27 pm »
WinAPI accepts param of type WPARAM, it's LongInt. In the EM_SETPASSWORDCHAR.

Zoran

  • Hero Member
  • *****
  • Posts: 1829
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: TEdit.PasswordChar should be of type WideChar
« Reply #12 on: January 29, 2022, 05:23:30 pm »
Why limit UTF8Length to 1?

Indeed, can be 4.

I believe that you misunderstood. I said, UTF8Length should be 1, and standard Length function can return up to 4, while UTF8Length still returns 1.

And LCL normally translates utf8 to what underlying widget's api expects, which in Windows would be an utf16 coded character.
« Last Edit: January 29, 2022, 05:28:13 pm by Zoran »

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: TEdit.PasswordChar should be of type WideChar
« Reply #13 on: January 29, 2022, 08:19:10 pm »
Why limit UTF8Length to 1?

Indeed, can be 4.

I believe that you misunderstood. I said, UTF8Length should be 1, and standard Length function can return up to 4, while UTF8Length still returns 1.

And LCL normally translates utf8 to what underlying widget's api expects, which in Windows would be an utf16 coded character.

Yes!! You are right. In this case the correct condition is:
UTF16Length is 1 to fit in WPARAM.

Because UTF8Length = 1 does not guarantee UTF16Length is not 2. In another way, it is limited to UCS-2.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: TEdit.PasswordChar should be of type WideChar
« Reply #14 on: January 29, 2022, 08:42:31 pm »
The API (i.e Windows) does not matter... It's for the LCL/WS to adapt the value so it can go to the API. Also the API is also qt, gtk, cocoa ....

The property is expected to hold a single "character". The LCL uses Utf8.

So, I say, the property should be TUtf8Char.

As for any limitation to what can be set to the property:
- Some checks (such as the byte sequence to be valid utf8) can be done in the property setter.
- Subset checks may depend... If some OS accept a bigger set of chars.... Then that may be a runtime check, with some fallback, or some other solution.

Of course, the smallest common subset can be chosen, but what if the next WS to be added has a smaller subset?



 

TinyPortal © 2005-2018