[CLOSED] LCLSendUTF8KeyPress always returns 1

[lagprogramming]

Follow up to:
Lazarus » Forum » Programming » LCL » [SOLVED] LCLSendUTF8KeyPress AUTF8Char parameter anomaly
Commit fa8f6ffa: LCL: Make AUTF8Char a var parameter in function LCLSendUTF8KeyPress.

lcl/lclmessageglue.pas has function LCLSendUTF8KeyPress(const Target: TWinControl; var AUTF8Char: TUTF8Char; IsSysKey: Boolean): PtrInt;

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

1. function LCLSendUTF8KeyPress(const Target: TWinControl; var AUTF8Char: TUTF8Char;
2.   IsSysKey: Boolean): PtrInt;
3. begin
4.   {if not IsControlKey then}
5.   Target.IntfUTF8KeyPress(AUTF8Char, 1, IsSysKey);
6.   Result := 1;
7. end;

It can be noticed that the function always returns 1.
The patch at the end of the post fixes the result assignment bug by changing the function to:

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

1. {******************************************************************************
2.  *                                                                            *
3.  *  LCLSendUTF8KeyPress                                                       *
4.  *                                                                            *
5.  *  Returns     : 0 to accept the message, non-zero to reject the message     *
6.  *                                                                            *
7.  *  Params                                                                    *
8.  *                                                                            *
9.  *  Target      : The Control that will recieve the message                   *
10.  *  AUTF8Char   : This is the UTF-8 encoded character. Check if this has      *
11.  *                changed after sending the message.                          *
12.  *  IsSysKey    : True if the Alt Key was also pressed.                       *
13.  *                                                                            *
14.  ******************************************************************************}
15. function LCLSendUTF8KeyPress(const Target: TWinControl; var AUTF8Char: TUTF8Char;
16.   IsSysKey: Boolean): PtrInt;
17. begin
18.   {if not IsControlKey then}
19.   if Target.IntfUTF8KeyPress(AUTF8Char, 1, IsSysKey) then
20.     Result := 1
21.   else
22.     Result := 0;
23. end;

The patch is

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

1. diff --git a/lcl/lclmessageglue.pas b/lcl/lclmessageglue.pas
2. index 56a50bcdbb..ae0d920e56 100644
3. --- a/lcl/lclmessageglue.pas
4. +++ b/lcl/lclmessageglue.pas
5. @@ -900,12 +900,28 @@ begin
6.    if ANotifyUserInput then NotifyApplicationUserInput(Target, Mess.Msg);
7.  end;
8.  
9. +{******************************************************************************
10. + *                                                                            *
11. + *  LCLSendUTF8KeyPress                                                       *
12. + *                                                                            *
13. + *  Returns     : 0 to accept the message, non-zero to reject the message     *
14. + *                                                                            *
15. + *  Params                                                                    *
16. + *                                                                            *
17. + *  Target      : The Control that will recieve the message                   *
18. + *  AUTF8Char   : This is the UTF-8 encoded character. Check if this has      *
19. + *                changed after sending the message.                          *
20. + *  IsSysKey    : True if the Alt Key was also pressed.                       *
21. + *                                                                            *
22. + ******************************************************************************}
23.  function LCLSendUTF8KeyPress(const Target: TWinControl; var AUTF8Char: TUTF8Char;
24.    IsSysKey: Boolean): PtrInt;
25.  begin
26.    {if not IsControlKey then}
27. -  Target.IntfUTF8KeyPress(AUTF8Char, 1, IsSysKey);
28. -  Result := 1;
29. +  if Target.IntfUTF8KeyPress(AUTF8Char, 1, IsSysKey) then
30. +    Result := 1
31. +  else
32. +    Result := 0;
33.  end;
34.  
35.  {******************************************************************************
36.  

After fixing this bug will someone also modify all "recieve" words in the file with "receive"!?

[AlexTP]

Posted to bugtracker,
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40224

[AlexTP]

Please answer the Juha's question: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40224#note_1363076286

[JuhaManninen]

After fixing this bug will someone also modify all "recieve" words in the file with "receive"!?

I fixed that.

[lagprogramming]

After fixing this bug will someone also modify all "recieve" words in the file with "receive"!?

I fixed that.

Regarding the code, look at the result assignment of function LCLSendCharEvent, the function above LCLSendUTF8KeyPress. Notice that it's result is also the result of DeliverMessage, like most of the function results in that file. There's no guarantee that the result is always zero but most of the times it is. LCLSendUTF8KeyPress never returns zero, always returns a one result, which is completely unnatural, another source of bugs. Both functions are designed to send characters, both functions return PtrInts, functions one on top of the other, in the same file. Imagine having an UTF8Pos function implemented that would return a different value than the traditional pos function when the search returns nothing. 
If the patch is accepted, LCLSendUTF8KeyPress will return zero if the key(TUTF8Char) was not handled because that's also the result of LCLSendCharEvent when the key is delivered without problems, and will return 1(a non-zero value) when the key was handled because that's when the key has been only partially delivered(equivalent of not fully/completely sending the message). Regarding result assignments, LCLSendUTF8KeyPress will try to mimic the behavior of LCLSendCharEvent, having the same zero and non-zero results(not exactly the same non-zero results, you get it).

Regarding the comment included in the patch, it has been added knowing that all comments regarding the returned values of the functions in that file have a significant flaw: the comments say what the caller functions should do with the messages based on the returned values instead of saying what is the meaning of the returned values(the results) for the called functions.
For example, "Returns : 0 to accept the message, non-zero to reject the message" has a different meaning than "Returns : 0 for success, non-zero for error code" or "for failure" or "for status code" or "for handled". They are not equivalent.
This is something that will have to be fixed in the entire file and will probably be a subject of it's own at a later time. The comment in the patch can be ignored because LCLSendCharEvent doesn't have a comment on top of it either. It has been added because when someone will decide to update those comments in that file, it should be easier for him.