Jump to content
robgab

Issue with TDialogService.InputQuery fmx for IOS

Recommended Posts

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 by robgab

Share this post


Link to post
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?

Share this post


Link to post

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

 

Share this post


Link to post
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 by Remy Lebeau

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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 ?

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×