Personas 3.0: Determine BDT Screen mode switching between Change and Display

[bradyfrey]

I am trying to understand the best way to determine if the BDT application is in Change or Display mode in a script. Our applications allow switching from change to display and display to change while viewing the detail screen of a record. When this happens, we need custom components to be enabled/disabled to match the standard components.

When opening the record at the initial screen and choosing either display or change, the onLoad event can recognize if the record is in change or display mode. We accomplished this by finding a standard element and reading the current state of that component. In this case it was a button where the icon displays a pencil (change mode) or glasses (display mode)

We understood that this would be a short term solution for our initial development. Now that our logic has evolved, we need a more consistent way to check the screen mode. This will allow the users to switch from display mode into change mode without having to exit the detailed screen and return by selecting a different state.

When switching from Display to Change while in the detailed screen, the onLoad event is not called. The onAfterRefresh and onBeforeRefresh both see the existing state of the components and not the To-Be state. We tried adding scripts to the Display / Change button but those events also only see the existing state.

Have others using Personas in a BDT application run into similar issues? Is there a better and more consistent way to get the resulting screen state (display vs change) when evoking the onAfterRefresh or onBeforeRefresh event?

Thanks,
Brady

[bradyfrey]

No. I meant to add this condition to my original write-up. There is always a possibility that the record is locked due to another user accessing it in change mode. That means we cannot assume that the mode has changed. If we were to make that assumption, the screen mode would remain in display mode, but we would be enabling our custom components.

[tamas_hoznek]

To query whether the switch to change mode was succeesful, you could use the 'enabled' property of an input field, which you know would be toggled, depending on the mode the transaction is in.

[bradyfrey]

This seems to have the same result as our other method. The standard input field is switched to enabled after the point that the onAfterRefresh is available.

[tamas_hoznek]

onAfterRefresh should see the current state... does it not? This surprises me.

[bradyfrey]

Tamas,

You may be right. It looks like the issue may be that the onAfterRefresh has stopped being evoked all together. The onAfterRefresh event is properly assigned to a script. However, it seems that the script is no longer being called. I created a test flavor stripped down to just the onLoad, onAfterRefresh and onBeforeRefresh.

The onLoad and onBeforeRefresh are being called as expected. The onAfterRefresh is never called after trying several different screen updates and button pushes. I will create an incident and attach this test flavor.

BASIS had recently updated several notes to bring the healthcheck up to date. I wonder if something in those updates had an adverse impact.

[tamas_hoznek]

Hi Brady,

Yes, we noticed yesterday that there is a problem with onAfterRefresh in the latest Personas client sources version. Our team is working on a fix. Sorry about the issue.

[bradyfrey]

Thanks, Tamas. No worries. Glad to know it is a known issue that is being worked.

[tamas_hoznek]

Well, if the onClick event for Display / Change sees the existing state, then the next state should be the opposite, no? 🙂