Table of Contents

Executing Task Dialogs and Reading Results

A task dialog gathers a decision and, often, some input — and your code needs both back after it closes. Execute shows the dialog on every supported framework, but how you read the result differs by target: a modal return value works where the framework blocks, while web and mobile targets are non-blocking. The portable pattern is to handle OnDialogResult, which fires with the chosen modal result on every platform, and to read any extra state (InputText, VerifyResult, RadioButtonResult, or a custom InputControl) from the dialog inside that handler. This guide covers cross-framework result handling, reading custom input values, and combining a built-in input with a verification checkbox in a single handler.

Cross-Framework Result Handling

Wire OnDialogResult when the same form code needs to run on desktop, mobile, and web targets. The event receives the modal result, and the dialog properties expose additional state such as VerifyResult, RadioButtonResult, and InputText. Read them inside the handler rather than relying on the Execute return value, which is only meaningful where the framework supports modal blocking.

procedure TForm1.ShowDeleteTaskDialog;
begin
  TMSFNCTaskDialog1.Title := 'Delete selected records';
  TMSFNCTaskDialog1.Instruction := 'Confirm how the selected records should be removed.';
  TMSFNCTaskDialog1.CommonButtons := [tcbOk, tcbCancel];
  TMSFNCTaskDialog1.VerifyText := 'Also remove linked attachments';
  TMSFNCTaskDialog1.Execute;
end;

procedure TForm1.TMSFNCTaskDialog1DialogResult(Sender: TObject;
  AModalResult: TModalResult);
begin
  if AModalResult = mrOk then
    ShowMessage(BoolToStr(TMSFNCTaskDialog1.VerifyResult, True));
end;

Reading Custom Input Values

For a custom input control, set InputType to titCustom, assign your control to InputControl, and read it back after the dialog closes — in OnDialogClosed or in the result handler. Cast InputControl to the control type you assigned and pull the value from that control's own API.

Combining result handling with built-in input

Most confirmation dialogs need an answer and a value. The example below uses a built-in text input for a project name and a verification checkbox for an optional side effect, then reads both InputText and VerifyResult from a single OnDialogResult handler — one dialog, one handler, two pieces of state:

procedure TForm1.ShowRenameDialog;
begin
  TMSFNCTaskDialog1.Title := 'Rename project';
  TMSFNCTaskDialog1.Instruction := 'Enter a new project name.';
  TMSFNCTaskDialog1.CommonButtons := [tcbOk, tcbCancel];

  // Built-in text input — value arrives in InputText after the dialog closes.
  TMSFNCTaskDialog1.InputType := titEdit;
  TMSFNCTaskDialog1.InputText := 'My Project';

  // Verification checkbox — state arrives in VerifyResult.
  TMSFNCTaskDialog1.VerifyText := 'Also rename the linked folder';

  TMSFNCTaskDialog1.Execute;
end;

procedure TForm1.TMSFNCTaskDialog1DialogResult(Sender: TObject;
  AModalResult: TModalResult);
begin
  if AModalResult <> mrOk then
    Exit;

  // Both pieces of dialog state are read from the same closed dialog.
  ApplyProjectName(TMSFNCTaskDialog1.InputText);
  if TMSFNCTaskDialog1.VerifyResult then
    RenameLinkedFolder(TMSFNCTaskDialog1.InputText);
end;

Common pitfalls

  • Relying on the Execute return value on web/mobile. Non-blocking targets return before the user answers. Always read the outcome in OnDialogResult for portable code.
  • Reading input before the result is mrOk. Check AModalResult first; reading InputText after a cancel applies a value the user rejected.
  • Casting InputControl to the wrong type. The cast must match the control you assigned to InputControl, and InputType must be titCustom for a custom control to be hosted at all.

See Also