| Ignoring Component-Changed State | KEVIN RESCHENBERG
05-07-2008 |
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 "unsaved data" message
</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 "unsaved data" msg
}
}
</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 "unsaved data" message
}
</script>
|
