nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Preview Issue - Requiring Save before Preview

krishnachaitanya

Hi All,
We are currently using TeamSite 7.1, and are facing the following issue.

We have a customized javascript that initializes the form and performs validations. Here, we have an event handler that checks whether the DCR has been modified, and this is called on click of the 'Preview' button. This method checks for the value returned by IWDataCapture.IsModified(), and when the value is TRUE, an alert is displayed, saying that the form has to be saved before previewing. However, with certain DCRs, this message is being displayed when the preview button is clicked, without any modifications done to the form. It'd be great if anyone could shed some light on the behaviour of the _DIRTY flag, and under what situations is the DCR marked as modified.

Thanks in advance,
Krishna Chaitanya

Find more posts tagged with

Comments

Adam Stoller

Hi All,
We are currently using TeamSite 7.1, and are facing the following issue.

We have a customized javascript that initializes the form and performs validations. Here, we have an event handler that checks whether the DCR has been modified, and this is called on click of the 'Preview' button. This method checks for the value returned by IWDataCapture.IsModified(), and when the value is TRUE, an alert is displayed, saying that the form has to be saved before previewing. However, with certain DCRs, this message is being displayed when the preview button is clicked, without any modifications done to the form. It'd be great if anyone could shed some light on the behaviour of the _DIRTY flag, and under what situations is the DCR marked as modified.

Thanks in advance,
Krishna Chaitanya

Are you saying the behavior is inconsistent for various DCRs of the same DCT-type - or that the behavior is inconsistent for different DCT-types but consistent within the DCT-types?

The former seems rather unlikely, the latter could be explained by other FormAPI code being run which causes the DCR to be marked as modified.

krishnachaitanya

Hi,
I have checked each of the javascripts that run during form load, using the IE8 javascript debugger, but could not come up with anything. However, this behaviour occurs only with certain DCRs, even though there is nothing that distinguishes them from other DCRs. It'd be great if you could give me more information on the scenarios where the DCR is marked as modified.

Thanks,
Krishna Chaitanya

Adam Stoller

Hi,
I have checked each of the javascripts that run during form load, using the IE8 javascript debugger, but could not come up with anything. However, this behaviour occurs only with certain DCRs, even though there is nothing that distinguishes them from other DCRs. It'd be great if you could give me more information on the scenarios where the DCR is marked as modified.

Thanks,
Krishna Chaitanya

You'll have to do the debugging yourself. See if you can identify a repeatable scenario with at least two DCRs (one that seems to always work and one that seems to always fail to work) and then examine those DCRs very carefully - my guess would be that there's something within the content of the DCR that might be causing problems, but that's just a wild short-in-the-dark guess.