Issue with TDialogService.InputQuery fmx for IOS

[robgab 0]

not sure if others are having this issue with Rad Studio 11.1 

seems when you call

 TDialogService.InputQuery and want to get a user input string it acts really strange, the ok button acts as the cancel button and the cancel button acts as the ok button and the value of the input from the user can't be obtained?

                  TDialogService.InputQuery('Please Enter Search Term', ['Info'], [search_word],
    procedure (const AResult : TModalResult; const values: array of string)
    begin

 

if AResult<.mrOK2 then exit;
       // Exit;     

   NewString:=Values[0]; // gets the value of the string input from the user

    end // end of dialog code
   );  // final end
any help would be kindly appreciated.

 

 

 

Edited August 3, 2022 by robgab

[Remy Lebeau 1394]

On 8/3/2022 at 5:22 AM, robgab said:

if AResult<.mrOK2 then exit;

What is '<.' ? What is 'mrOK2'?  Did you mean 'if AResult <> mrOK then ...' instead?

[robgab 0]

Correct , 

I Also tried the new call method as well

ASyncService.InputQueryAsync from Embarcadero and it also fails too,

 

if TPlatformServices.Current.SupportsPlatformService (IFMXDialogServiceAsync, IInterface (ASyncService)) then begin

                           with   ASyncService do begin

                  ASyncService.InputQueryAsync('Please Enter Search Term', ['Info'], [search_word],
    procedure (const AResult : TModalResult; const values: array of string)
    begin

    case AResult of

    mrOk :
    begin
    NewString:=Values[0];  //showmessage('ok pressed');
     end;

    mrCancel :
    begin
    NewString:=Values[0]; //showmessage('cancelled pressed');
    end;

    end; // end of case

   );  // final end

 

[Remy Lebeau 1394]

15 hours ago, robgab said:

I Also tried the new call method as well

ASyncService.InputQueryAsync from Embarcadero and it also fails too,

I can't attest to the behavior of the OK and Cancel buttons.  But one problem I see is your NewString variable. Where is it declared, and where is it used after the dialog closes? Remember, this dialog is asynchronous, so make sure you are not accessing NewString out of scope.

 

Also, your 'with ASyncService' block is being wasted and should be removed.

Edited August 5, 2022 by Remy Lebeau

[Scott Slater 1]

I can confirm this behavior in Delphi 11.1.  Try the following code in iOS.

TDialogService.InputQuery('Enter some value', [''], [''],
  procedure(const AResult: TModalResult; const AValues: array of string)
  begin
    case AResult of
      mrCancel: ShowMessage('Cancel');
      mrOK:     ShowMessage('OK');
    end;
  end);

If you press OK you will get "Cancel". 

If you press Cancel you will get "OK". 

If you press Return on the keyboard you will get "OK".

 

The combination of nonsensical return values from the dialog make using it practically impossible.

[Scott Slater 1]

This has already been fixed according to QP.  In the comments, there is a provided temporary fix until an update comes out.

https://quality.embarcadero.com/browse/RSP-37702

[DelphiMT 5]

This issue is still listed as "Open" in QP. It makes our iOS app unusable.

[Scott Slater 1]

1 hour ago, DelphiMT said:

This issue is still listed as "Open" in QP. It makes our iOS app unusable.

I followed the temp fix provided in the QP entry and it has solved it for me for now.  Just make a copy of the FMX.Dialogs.iOS.pas into your project folder and add edit it according to the QP.  Recompile and it should work as expected.  Once the next update to Delphi is released that includes the fix, simply delete the FMX.Dialogs.iOS.pas from your project folder and recompile.

[DelphiMT 5]

I'll give that a try - thanks so much!

[Rollo62 536]

I'm a little unsure about this fix is repairing now all cases.

 

I had implemented some fixes in the FMX.Dialogs.iOS.pas file at different spots ( under constructor TFMXAlertViewInputDelegate.Create ) and

have seen that Dave Nottage provided a fix RSP-37702 under "class function TCocoaDialogsService.CreateAlertView(".

This fix now seems to be implemented in the original Delphi unit in Rx11.2 Patch1.

 

I would remove this patched FMX.Dialogs.iOS.pas unit now from my "patched units" list, if there were no other known sideeffects with this unit.

Still I'm trying to check all the places where this error might occur, but its a little hard to test all that.

 

Has somebody maybe found any other dialog sideeffects, related where the buttons are mixed up, or is this original Delphi unit now 100% OK ?