Perspective pop up confirm

Ignition Early Access
1

I have a view with various items that are saved to a table once the user presses save.

I want to add a pop up so they have to confirm to save or exit, that’s easy enough but do I need to pass all the values through to the pop up or is there an easier way? The pop up has a exit button that closes the popup and a save button that performs the sql update.

2

So… there’s a couple of ways you could handle this:

  1. Pass the parameters to the popup, and as part of the confirm button press, perform the necessary SQL calls. This of course requires setting params on the confirmation View used in the Popup, as well as configuring the Popup action to pass the parameter along, which means you either need to configure the Script Action correctly and supply the params in a dictionary to the openPopup call or bind to your value in the Popup Action UI. Works perfectly, but it’s messy.

  2. Configure a Script for whatever component or View is currently storing your data values which listens for a “SQLCOMMITCONFIRMED” message type and listen on the page or session level (NOT view). Your confirm button in the popup should broadcast this messageType at the Page or Session level (NOT view). This method is much cleaner because you don’t have to pass parameters around and the script to commit the data is essentially located on the same component, making for easy maintenance.

3

Thankyou,

So to dumb that down, the sql update script is waiting on the button to report back a ‘true’ value at session level to perform.

if save button on popup = true
 "perform sql update"
4

Sort of.

The script which would run the query lives on a Component named CommitButton, which lives on ViewA.
CommitButton has a configured script (right-click, select “Configure Scripts”) which is a Message Handler (select “Add handler…” on the Script Configuration dialog) which is listening for a messageType of “SQLCOMMITCONFIRMED”.
This script does not care what value is sent along in the message payload, because the only way to broadcast the SQLCOMMITCONFIRMED messageType it is to click the ConfirmButton in ViewB. So if the “SQLCOMMITCONFIRMED” message is broadcast at all, then the ConfirmButton button MUST have been clicked. Our logic in this script must then just be to run our SQL Query.

1 Like
5

ConfirmPopupProject.zip (10.3 KB)
This is from a nightly version of 8.0.3, so you will be unable to import the project if on an older version.

This project includes a Page Configuration for ViewA.
ViewA contains a Text Field and a Button.
Data put into the Text Field is stored in a custom property of the Button via a binding on Button.custom.data
Clicking the button opens a popup with confirm/cancel buttons.
Clicking Confirm in the popup broadcasts a messageType of “SQLCOMMIT"CONFIRM” at the page scope.
Clicking Cancel in the popup closes the popup without sending any message.
When the “SQLCOMMITCONFIRM” messageType is broadcast, the Button hears the broadcast via a configured script, and writes the stored data from Button.custom.data to a nearby Label component.

6

I think I’ve got it. Rather then script you have in the message handler to store data from the button I can have the sql update query in there.

I have many tablets across the plant so at simultaneous times data can be entered and there is different views depending on what QC data is being entered. Do I need to distinguish which SQLCOMMITCONFIM is doing what, or it will only listen on the view to pop up is on, if that makes sense ?

Many thanks for your help, this is so much easier then having to pass all the parameters to the popup.

7

This is where the "scope" of the message comes into play, both in the sendMessage() call and on the listener.

Scopes:

  • View can only be heard by listeners WITHIN the Same View who are listening for view-scoped broadcasts. In your use case, if you used this broadcast scope in your Popup, then the Button on the PAGE would never hear the message because your Popup View is not within the View which contains the CommitButton component.
  • Page can only be heard by any listeners in this View or other Views contained within this page (including Docked Views and Popups) which are listening for page-scoped broadcasts. This is what I recommend you sue because the broadcast from the Popup can be heard by the background Page.
  • Session will be heard by any listeners in any open tabs in your workspace which are listening for session-scoped messages.

So if you configure the ConfirmButton Component's sendMessage script to use the "page" scope, and you configure the CommitButton Component to only listen on the the "page" scope, then anything happening in other tabs will not be heard, even if it uses the same messageType.

There is an edge case where you could press the commit button, then navigate to a different View which also has a listener of the same messageType - while the Popup is still open - and then confirm, which would now trigger the new View's listener. To avoid this, you could structure the messageType to include the id of the opened Popup; this would enforce that a Popup could only confirm a commit for the View it was opened from. Alternatively, you could provide the messageType as a parameter to the Popup - but that's what you were trying to avoid in the first place.

8

That make sense, Just implemented it and its working great. Thanks again.

2 Likes