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...

Until next time...