May 7, 2008

Ignoring Component-Changed State

I've mentioned the component-changed state a few times in the past. A component is always aware of whether any data has been changed, either by the user or by PeopleCode. This then determines whether Save processing code runs and whether the "You have unsaved data" warning/prompt is displayed. It's easy to tell a component that data has changed—either change some data in the buffer or call the SetComponentChanged() function.

It's not so easy to tell the component to forget the changes that have been made. There is the DoCancel() function, but it returns either to a search dialog or to nothingness (no component active and only the menu visible). I've been developing a number of self service pages, and this is one area where we can have an issue with the component-changed state. How can we implement a simple Cancel button, for example, that does what would be expected: Ignore any changes and transfer to another page such as a user-friendly menu?

In a previous post I described a method that works well for pages that contain only derived fields. This involves going through Save processing for both the Save and Cancel buttons, doing database saves only when appropriate, and ending up with a component or page transfer. But that won't work if your component contains any "real" fields (those that represent columns in a physical table). I had mentioned the idea of tricking the JavaScript that triggers the "unsaved data" warning but called that too aggressive. (Not sure why I worded it like that!) Today we'll just go ahead with the trickery. In an HTML Area on the page:

<script type="text/javascript">
  win0.ICChanged.value = "-1";    // Suppress the "unsaved data" prompt
</script>

If you do a "view source" on the page and look at the code that displays the warning message, you can see that it is skipped when this ICChanged hidden field contains a value of -1. And that's it. Warning message defeated. I don't normally like affecting the delivered JavaScript in this way, but in this case it seems much better than, for example, undoing a save after the fact. Now if only we had a ClearComponentChanged() function...

5/18/2009 update: Jiju writes, "I am not sure whether this code will always work in Enterprise Portal. When a component is accessed through Enterprise Portal it is very probable that there can be values other than win0 (like win_1, win_2 etc.). In that scenario this may not work." I don't have access to Enterprise Portal, so if you are using the code above, do a View Source to see what else might be going on and make changes as needed.

11/6/2009 update: Jon clears up another piece of the puzzle: "The issue described in the update also occurs if the user clicks the "New Window" link. Each time a new window is created the win* value goes up by one. I thought you might be interested in our local workaround:

<script type="text/javascript">
for (i = 0; i < document.forms.length; i++) {
  if (document.forms[i].name.substring(0,3) == "win") {
    document.forms[i].ICChanged.value = "-1"; // Suppress the "unsaved data" prompt
  }
}
</script>

"This javascript loops over all forms on the page looking for ones named win* and sets the ICChanged value accordingly."

5/5/2010 update: Joe offers another tip: "I think the best solution to the changing "winN" problem is to use the meta-HTML %Formname variable, instead of hard-coding win0:"

<script type="text/javascript">
  %Formname.ICChanged.value = "-1";    // Suppress the "unsaved data" prompt
}
</script>

Until next time...