After the last few posts, you should be getting comfortable sharing data between multiple apps. That leaves us the last of our original four conceptual areas to cover off : Actions.

Just as App Tethering allows you to share pieces of data out to remote applications, it also allows you to share TActions (strictly speaking, any TCustomAction descendant, but I’ll use TAction for short). Right now you’ve possibly got at least one button or menu item connected to a TAction somewhere in your app. More likely you have dozens of them. Shared Actions let you expose these TActions unchanged, so they can be triggered from remote apps as well.

It’s probably easiest to add one first before we discuss further, so bring up App1 and add a TActionList to the main form. Double-click on it to bring up the ActionList Editor and add a new Action. Set the Action’s Name to actReset and its Text to Reset. In this Action we’re going to reset all the components we’ve been using to display the various shared data resources over the last few posts. In the Action’s OnExecute event add the following code.

For Delphi:

procedure TForm3.actResetExecute(Sender: TObject);
begin
  Edit1.Text := '';
  Label2.Text := '';
end;

For C++:

void __fastcall TForm1::actResetExecute(TObject *Sender)
{
  Edit1->Text = "";
  Label2->Text = "";
}

In the action’s OnUpdate event, put the following code.

For Delphi:

procedure TForm3.actResetUpdate(Sender: TObject);
begin
  actReset.Enabled := (Edit1.Text <> '') OR
                      (Label2.Text <> '');
end;

For C++:

void __fastcall TForm1::actResetUpdate(TObject *Sender)
{
  actReset->Enabled = (Edit1->Text != "") ||
                      (Label2->Text != "");
}

Lastly, drop a button on the form and connect its Action property to your newly created actReset.

So, we’re clearing Edit1 and Label2, but the action (and by extension the button) is only enabled if those control are not already clear.

If you’ve ever used Actions before, hopefully nothing there is surprising (well, except perhaps the fact that I couldn’t come up with a better scenario than clearing the controls). Importantly, nothing there has anything to do with App Tethering: actReset is a purely local TAction.

How do we share it with our remote App? In App1, go to your TetheringAppProfile1 component. Earlier we saw that it had a Resources property that contained all the resources it was sharing with remote apps. You should also see that it has an Actions property. Bring up its property editor and add a new TLocalAction. Set its Name to lactReset, and point its Action property to actReset. You’ll note it has a Kind property, just like our persistent resources, and like those, we’ll set it to Shared.

That’s all we need to do in App1. In App2, what we do depends on how you want to trigger this action. If all you want to do is trigger it from code, then drop a TButton onto App2’s main form and in the OnClick event write the following code.

For Delphi:

procedure TForm4.Button2Click(Sender: TObject);
begin
  TetheringAppProfile1.RunRemoteAction(TetheringManager1.RemoteProfiles.First,
                                       'lactReset');
end;

For C++:

void __fastcall TForm2::Button2Click(TObject *Sender)
{
  TetheringAppProfile1->RunRemoteAction(TetheringManager1->RemoteProfiles->First(),
                                        "lactReset");
}

Provided the remote profile we specify in the first parameter has a TLocalAction named ‘lactReset’, and provided the connected TAction is enabled, it will be executed.

If that’s all we want to do, then we’re done. However, we may want a TAction in App2 that we can connect to Buttons, Menu Items, etc that acts as a proxy to the action in App1. In that case, add a TActionList to App2 and create a new TAction in it. This time don’t give it an OnExecute or OnUpdate event. This action will be our local proxy, but doesn’t need any execution logic as that will be happening remotely.

Next, add a TLocalAction to App2’s TetheringAppProfile.Actions property. Set its Name to lactReset (to match the one in App1), set its Kind to Mirror and lastly point its Action property at the new TAction you just created.

Lastly, clear out the button event handler you just wrote to call RunRemoteAction (or alternately, add another button) and connect its Action property to your newly created TAction.

I realise all that might be a little confusing, what with every second word ending in Action, so at a high level here’s what we have:

In App2 we have a TAction, which is connected to lactReset, our TLocalAction. This TLocalAction is actually a mirror of a shared TLocalAction in App1, which is connected to a TAction called actReset which contains the actual logic that will run.

Start both apps and click Connect in App1. You should then be able to share some text resources both ways, and then click your button in App2 and see the label and edit box in App1 get cleared.

On the network, this is actually pretty simple. This is not like a remote procedure call where we need to marshall\unmarshall parameters and return values. All we’re doing is triggering an Action, so the action name is all that is sent over the wire. In the image below you can see the RUN_ACTION constant in the network packet, followed by the action name, lactReset.

The following packet is the RES_RUNOK acknowledgement coming back.

One last thing on Actions before we end for the day. When you added the very first Action to your TetheringAppProfile1 component in App1, I got you to set the name to lactReset and the Kind to Shared.

Notice the very bottom property, NotifyUpdates. If you are using RAD Studio XE8 Update 1 (or later), this indicates whether you want the remote actions to be updated when the local TAction changes. For example, in our case in actReset’s OnUpdate event, we are disabling it if there is no text in the edit box and the label, and enabling it if there is text in either of them. If you set NotifyUpdates to True, this change in the enabled property will be sent to the remote actions, so our button in App2 will enable and disable in sync with the button in App1.

NotifyUpdates defaults to False, as depending on the Action this could end up being quite chatty over the network.

So now you’ve done enough to build some pretty useful apps. You can find and connect your apps, share all sorts of data, and trigger actions.

We’ve only run App1 and App2 on Windows so far, but they are Multi-Device apps, so try running them on some mixture of Windows, Android, iOS and OSX. Provided the machines are all on the same subnet, the code should work as is, and if not, try passing in the Target details to AutoConnect as we looked at way back in the second article.

Next up, I think it’s time to come good on a promise I made earlier. I said there were three ways to find other apps, but so far we’ve only discussed one: AutoConnect. In the next article I’ll fix that.

You can get the source for the sample apps at this stage of the series, in both C++ and Delphi, but to really understand what is going on there is no substitute for building the apps yourself. They aren’t that big.