Perspective closePopup Fails When 'is not' Aborts the Handler

Which hops does the import message cross?

Start with the data path. A button click in the ImportFile popup, a message handler on a component in the parent view, a project-library stored procedure call, and a close instruction back to the browser page are all involved. Every one of those scripts executes on the Ignition gateway inside the Perspective session. The browser only renders the result.

A row in the database proves hop 4 ran. It does not prove the handler reached hop 5. The packet stops between 4 and 5.

Where does the handler stop before closePopup?

The handler stops on this line, which runs inside the for loop right after the sproc call:

if str(res) is not "Success":
    raise ValueError('Sproc call failed for row {}. Result: {}'.format(row, str(res)))

is and is not test object identity, not string equality. The string returned by the sproc wrapper, or produced by str(res), is a different object from the literal "Success". The identity test therefore evaluates true even when the procedure succeeded. The sequence is deterministic:

1. The first CSV row that does not already exist is inserted. This is the sproc execution you can see in the database.
2. res comes back as a success string, and str(res) is not "Success" evaluates true.
3. ValueError is raised with a message ending in Result: Success.
4. Control jumps to except, which tries to open ErrorModal and logs a warning.
5. sendMessage('refreshTree'), sendMessage('refreshStatesTable') and closePopup("ImportFile") never execute. Every remaining CSV row is skipped.

This fault leaves two signatures. First, exactly one new row is inserted per import regardless of CSV length. Second, if ErrorModal opens, it reports a failure whose result text is Success. There is also a quick confirmation test. Import a CSV whose rows all already exist. Every row hits continue, no comparison runs, and the popup closes. If the popup closes on the all-duplicates file and stays open on a file with new rows, the comparison is the cause.

The fix is !=. Normalize the return value too, because a stored procedure wrapper can return a Java string, a unicode string, or a value with trailing whitespace:

if str(res).strip() != 'Success':

Which other faults leave the popup open?

Several other faults leave the popup open with the sproc still firing. Rule each one in or out with a specific check:

Why don't the logger lines show up?

Perspective loggers do not write to a browser or Designer console. The scripts run on the gateway, so system.util.getLogger('insertStates_message') writes to the gateway log. Read it in the gateway web interface log viewer, under Status > Diagnostics > Logs, and filter on the logger name. system.perspective.print is the only call here whose output reaches the browser console or Designer output.

If the gateway log contains none of the handler's logger lines, including the unconditional running the message handler, while rows still appear in the database, the edited code is not the code that ran. Save the project, confirm the session is running against the saved revision (close and reopen the session), and search for every importStates handler on the page. Only after the log shows running the message handler is the handler you are editing the one that ran.

Fix the logging calls at the same time. logger.warn('There was an error: ' + str(e)) reduces the exception to its message and discards the stack trace. Pass the exception as a separate argument, as in logger.warn('There was an error', e), for Java throwables. For Python exceptions, append traceback.format_exc() so the log shows the failing line.

Where should the popup close: handler or button?

You can place the closePopup call in three places. They differ in whether the close depends on the insert actually succeeding:

Use approach A. It is the existing design, it already gates the close on success, and it only fails because of the comparison bug. The page-scoped popup id resolves correctly from a component handler on the same page, so closePopup("ImportFile") needs no sessionId or pageId arguments. Move to approach C if operators need per-row feedback inside the popup.

What does the corrected handler look like?

The corrected handler keeps the insert loop and closes only after every row succeeds. It catches Java and Python exceptions separately and logs at each hop so the gateway log shows exactly where execution stopped.

def onMessageReceived(self, payload):
    import java.lang
    import traceback
    logger = system.util.getLogger('insertStates_message')
    logger.info('importStates received on ' + str(self.view))

    def showError(msg):
        system.perspective.openPopup('ErrorModal', 'GlobalComponents/Modals/ErrorModal',
                                     {'ModalName': 'ErrorModal', 'ErrorMessage': msg})

    try:
        pyData = system.dataset.toPyDataSet(payload.get('csvDS'))
        existingData = system.dataset.toPyDataSet(self.view.custom.Data)
        lineId = self.view.params.ID
        inserted = 0
        for row in pyData:
            if any(r['ReasonCode'] == row['ReasonCode'] and r['LineID'] == lineId for r in existingData):
                logger.warn('ReasonCode {} already exists on LineID {}'.format(row['ReasonCode'], lineId))
                continue
            params = {
                'AltCode': row['AltCode'],
                'OperatorSelectable': row['OperatorSelectable'],
                'SubReasonOf': row['SubReasonOf'],
                'StateID': 0,
                'LineID': lineId,
                'Description': row['Description'],
                'DowntimeCategoryCode': row['DowntimeCategoryCode'],
                'DisplayColor': row['DisplayColor'],
                'PlannedDowntime': row['PlannedDowntime'],
                'ReasonCode': row['ReasonCode'],
                'RecordDowntime': row['RecordDowntime'],
                'IconPath': row['IconPath'],
                'StateTypeID': row['StateTypeID']
            }
            res = mes.config.sp.addEditLineState(params)
            if str(res).strip() != 'Success':
                raise ValueError('Sproc failed for ReasonCode {}: {}'.format(row['ReasonCode'], res))
            inserted += 1

        logger.info('Inserted {} rows, closing ImportFile'.format(inserted))
        system.perspective.sendMessage('refreshTree')
        system.perspective.sendMessage('refreshStatesTable')
        system.perspective.closePopup('ImportFile')

    except java.lang.Throwable as t:
        logger.error('importStates Java exception', t)
        showError(str(t))
    except Exception as e:
        logger.warn('importStates failed: ' + traceback.format_exc())
        showError(str(e))

Three decisions are embedded in this code:

• LineID source. The original duplicate check compared row["LineID"] from the CSV, but the insert wrote self.view.params.ID. If those differ, the check passes and the insert duplicates. The version above uses the view's ID for both. If the CSV LineID is authoritative, use it for both instead. Never mix the two sources.
• Per-row toast. The per-row gpa.frontEnd.localUI.throwSuccess calls are removed from the loop. Any exception inside that helper would also abort the loop before closePopup. Report one summary after the loop if needed.
• Partial imports. Rows inserted before a failure stay committed. If a partial import is unacceptable, move the loop into a single transaction in the project library.

What needs fixing on the popup side?

The popup's onClick script has three defects:

1. Dataset clear. system.dataset.clearDataset() returns a new, empty dataset and does not modify its argument. The original line discards the result, so csvDict is never cleared. Assign it back: fu.custom.csvDict = system.dataset.clearDataset(fu.custom.csvDict), where fu = self.parent.parent.getChild('FileUpload').
2. Type mapping. type_mapping[str(self.view.params.Type)] raises KeyError on an unmapped type, so the if messageType: guard never runs. Use type_mapping.get(str(self.view.params.Type)) and log when it returns None.
3. Logging. Replace logger.warn('There was an error: ' + str(e)) with a call that preserves the stack trace, as in the handler.

Clearing the upload properties right after sendMessage is safe. The payload already holds the CSV string and dataset reference, and Ignition datasets are immutable, so the handler keeps its copy.

How do you verify the fix?

1. Save the project, then close and reopen the Perspective session so it loads the saved revision.
2. Open the gateway log viewer and filter on insertStates_message and importFile.
3. Import a CSV with three new rows. Confirm importStates received on ... appears once. If it appears twice, a second handler exists on the page.
4. Confirm the database gained three rows, not one, all with the intended LineID.
5. Confirm the log shows Inserted 3 rows, closing ImportFile, the tree and states table refresh, and the popup closes.
6. Re-import the same CSV. Expect three already-exists warnings, zero inserts, and the popup closing.
7. Force a failure, for example by passing an invalid StateTypeID. Confirm the popup stays open, ErrorModal shows the procedure's actual result, and the gateway log carries a full stack trace.
8. Reopen ImportFile and confirm the FileUpload custom properties configCSV and csvDict are empty before selecting a new file.

FAQ