HowTo: show a confirmation dialog with Delphi FireMonkey UI library

Here’s my answer at https://stackoverflow.com/a/71728787/903783 on how to show a confirmation dialog with Delphi’s cross-platform FireMonkey UI library.

Based on other answers, I’ve added a “Confirm” class function (adapted to return a Boolean) to TApplicationHelper (which also has an untested function to get the executable filename), currently maintained under the READCOM_App repository.

Update: had to modify the answer to use a callback so that it also works on platforms where FMX supports only asynchronous dialogs, like Android

unit Zoomicon.Helpers.FMX.Forms.ApplicationHelper;

interface
uses
  FMX.Forms; //for TApplication

type
  TApplicationHelper = class helper for TApplication
  public
    function ExeName: String;
    class function Confirm(Prompt: String): Boolean;
  end;

implementation
  uses
    {$IFDEF ANDROID}
    System.SysUtils, //TODO: is this needed?
    Androidapi.Helpers, //for TAndroidHelper, JStringToString
    Androidapi.Jni.JavaTypes, //to avoid "H2443 Inline function 'JStringToString' has not been expanded"
    {$ENDIF}
    System.UITypes, //for TMsgDlgType
    FMX.DialogService, //for TDialogService
    FMX.Dialogs; //for mbYesNo

{$region 'TApplicationHelper'}

//from https://gist.github.com/freeonterminate/2f7b2e29e40fa30ed3c4
function TApplicationHelper.ExeName: String;
begin
  Result := ParamStr(0);

  {$IFDEF ANDROID}
  if (Result.IsEmpty) then
    Result := JStringToString(TAndroidHelper.Context.getPackageCodePath);
  {$ENDIF}
end;

//based on https://stackoverflow.com/questions/42852945/delphi-correctly-displaying-a-message-dialog-in-firemonkey-and-returning-the-m
class procedure TApplicationHelper.Confirm(const Prompt: String; const SetConfirmationResult: TProc<Boolean>);
begin
  with TDialogService do
  begin
    PreferredMode := TPreferredMode.Platform;
    MessageDialog(Prompt, TMsgDlgType.mtConfirmation, mbYesNo, TMsgDlgBtn.mbNo, 0,
      procedure(const AResult: TModalResult)
      begin
        //Note: assuming this is executed on the main/UI thread later on, so we just call the "SetResult" callback procedure passing it the dialog result value
        case AResult of
          mrYes: SetConfirmationResult(true);
          mrNo: SetConfirmationResult(false);
        end;
      end
    );
  end;
end;

{$endregion}

end.

usage example is in the MainForm of READCOM_App

procedure TMainForm.HUDactionNewExecute(Sender: TObject);
begin
  TApplication.Confirm(MSG_CONFIRM_CLEAR_STORY, //confirmation done only at the action level //Note: could also use Application.Confirm since Confirm is defined as a class function in ApplicationHelper (and those can be called on object instances of the respective class too)
    procedure(Confirmed: Boolean)
    begin
      if Confirmed and (not LoadDefaultDocument) then
        NewRootStoryItem;
    end
  );
end;

where MSG_CONFIRM_CLEAR_STORY is declared as

resourcestring
  MSG_CONFIRM_CLEAR_STORY = 'Clearing story: are you sure?';

Using cross-platform fswatch utility for monitoring file system changes

I was just looking for a way to monitor for file system changs in a cross-platform way.

After searching the answers at a related question on StackExchange and the ones at the other question mentioned as possible duplicate in that question’s comments, I think I’d go with fswatch since it is has cross-platform support. Contributed the following answer to collect info I gathered on fswatch.

It uses different kinds of monitors for different OS and can choose the appropriate one automatically, or allow one to specify which one to use and even pass custom platform-specific parameters to the respective monitor.

The list of monitors it currently supports is:

· A monitor based on the File System Events API of Apple OS X.

· A monitor based on kqueue, an event notification interface introduced in FreeBSD 4.1 and supported on most *BSD systems (including OS X).

· A monitor based on inotify, a Linux kernel subsystem that reports file system changes to applications.

· A monitor based on File Events Notification, a Solaris/Illumos kernel API that reports file events.

· A monitor based on ReadDirectoryChangesW, a Microsoft Windows API that reports changes to a directory.

· A monitor which periodically stats the file system, saves file modification times in memory and manually calculates file system changes, which can work on any operating system where stat (2) can be used.

It seems to be available via apt-get on Debian/Ubuntu Linuxes. See how to install via apt-get and use fswatch.

FreeBSD and OS-X package-based installation support for fswatch is provided by its author.

Can also build and install it at other OSes, found an article+video showing how to make and install fswatch on CentOS.

There is also an other article that shows the same manual process to build/install (and use) fswatch for Linux.

Windows-based package-based installation support doesn’t seem to be available yet (e.g. no package for Chocolatey yet, and no package for Vcpkg)

There is also extensive documentation for fswatch, though docs for the latest 1.5 version point to 1.4 ones currently. See how to convert commands for fswatch 0.x to fswatch 1.x

Tips for manually choosing a monitor (currently not updated to mention all monitors)

Read about fswatch usage here, here and here and a tutorial intro here

A library named libfswatch is kept in sync with the fswatch tool. See here and a newer doc here. Note that the library is versioned differently from fswatch utility itself. Specifically, the 1.14.0 library doc states:

"libtool’s versioning scheme is described by three integers: current:revision:age.

· current is the most recent interface number implemented by the library.

· revision is the implementation number of the current interface.

· age is the difference between the newest and the oldest interface that the library implements.

Beware that there is also another similar s/w called fswatch (that is go-related I think).