How to force submit if values change

[DJ]

I have a .NET datagrid that has a column of dropdownlist controls. If the
user changes the value in the dropdown in one or more rows I will set a
flag. If the user subsequently attempts to (1) leave the page, or 2) close
the window, I want to present an Alert reminding them to first submit their
data.

Anyone know how to do this?

TIA,
Dewey

[George Jempty]

Re: How to force submit if values change

DJ wrote:[color=blue]
> I have a .NET datagrid that has a column of dropdownlist controls. If the
> user changes the value in the dropdown in one or more rows I will set a
> flag. If the user subsequently attempts to (1) leave the page, or 2) close
> the window, I want to present an Alert reminding them to first submit their
> data.
>
> Anyone know how to do this?[/color]

Yes.

What have you tried?

I would try an onunload event that in turn calls the confirm() (NOT
alert()) method. Then depending on how you want to branch, on confirm()
returning true (user hits "OK") or false (user hits "Cancel"), call the
appropriate form's submit() method.

HTH

[Michael Winter]

Re: How to force submit if values change

On Fri, 20 Feb 2004 23:59:16 -0600, DJ <reply@group.ne t> wrote:
[color=blue]
> I have a .NET datagrid that has a column of dropdownlist controls. If
> the user changes the value in the dropdown in one or more rows I will
> set a flag. If the user subsequently attempts to (1) leave the page,
> or 2) close the window, I want to present an Alert reminding them to
> first submit their data.
>
> Anyone know how to do this?[/color]

I very much doubt it.

If this is for the Internet, then it's impossible. The onunload event is
about your only option I can see, but not all browsers fire that event
under the same conditions.

If this is for an Intranet, or some other restricted environment, and you
can guarantee that your users have either Mozilla or Internet Explorer,
then you can use the onunload event in the BODY tag where you can perform
those checks. However, you can't prevent the browser from closing. Even if
you can check the state of the page, you might not be able to do anything
anyway: the browser is closing, so it's not likely to start opening new
connections. The behaviour will probably be similar when changing pages.

The reason for those browsers in particular is because, out of the ones I
have available (Netscape, Mozilla, IE and Opera), only they will fire
onunload when closing. There might be other browsers, of course.

Your best bet is to make it clear to your users that closing or navigating
away without saving will cause data loss.

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Michael Winter]

Re: How to force submit if values change

On Sat, 21 Feb 2004 15:33:20 GMT, Michael Winter
<M.Winter@bluey onder.co.invali d> wrote:
[color=blue]
> On Fri, 20 Feb 2004 23:59:16 -0600, DJ <reply@group.ne t> wrote:[/color]

[snip]
[color=blue][color=green]
>> Anyone know how to do this?[/color]
>
> I very much doubt it.[/color]

[snip]

Oops. I read that question, for some bizarre reason, as: "Can this be
done?"

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[George Jempty]

Re: How to force submit if values change

Michael Winter wrote:[color=blue]
> On Fri, 20 Feb 2004 23:59:16 -0600, DJ <reply@group.ne t> wrote:
>[color=green]
>> I have a .NET datagrid that has a column of dropdownlist controls. If
>> the user changes the value in the dropdown in one or more rows I will
>> set a flag. If the user subsequently attempts to (1) leave the page,
>> or 2) close the window, I want to present an Alert reminding them to
>> first submit their data.
>>
>> Anyone know how to do this?[/color]
>
>
> I very much doubt it.
>
> If this is for the Internet, then it's impossible.[/color]

Mr Winter, please don't take this the wrong way, but your statements
above are simply wrong in the light of some experiments I've been doing.

It is a simple matter to do this with Explorer and Mozilla in scenario
(1) where the user leaves the page. The very same way I suggested in my
original reply.

Scenario (2) is trickier, but can be done if the data entry window is a
child window; i.e. a popup. onunload just have the window being closed
write its form data to a (hidden) form in the opener. The window being
closed could then either submit this form in the opener, or perhaps more
politely, using the DOM a submit button could be made to appear on the
opener.

[Lasse Reichstein Nielsen]

Re: How to force submit if values change

George Jempty <fleetwoodd@bel lsouth.net> writes:
[color=blue]
> Michael Winter wrote:[/color]
[color=blue][color=green]
>> If this is for the Internet, then it's impossible.[/color]
>
> Mr Winter, please don't take this the wrong way, but your statements
> above are simply wrong in the light of some experiments I've been
> doing.[/color]
[color=blue]
> It is a simple matter to do this with Explorer and Mozilla in scenario
> (1) where the user leaves the page.[/color]

That is the point! Explorer and Mozilla are *not* the internet. Will the
solution work in Opera? (Which, e.g., I use as my browser)
Will it work in Safari?
Will it work on a mobile phone based browser? (which is likely to
be Opera again :).
Will it work for the 10% of people who browse without Javascript?

If the internet is the intended audience, you can not rely on the
ability to execute code before the user leaves a page.

There is no problem in *trying* to give a warning, and in some
browsers it will work, but it is not possible to *always* do so.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[George Jempty]

Re: How to force submit if values change

Lasse Reichstein Nielsen wrote:
[color=blue]
> George Jempty <fleetwoodd@bel lsouth.net> writes:
>
>[color=green]
>>Michael Winter wrote:[/color]
>
>[color=green][color=darkred]
>>>If this is for the Internet, then it's impossible.[/color]
>>
>>Mr Winter, please don't take this the wrong way, but your statements
>>above are simply wrong in the light of some experiments I've been
>>doing.[/color]
>
>[color=green]
>>It is a simple matter to do this with Explorer and Mozilla in scenario
>>(1) where the user leaves the page.[/color]
>
>
> That is the point! Explorer and Mozilla are *not* the internet. Will the
> solution work in Opera? (Which, e.g., I use as my browser)
> Will it work in Safari?
> Will it work on a mobile phone based browser? (which is likely to
> be Opera again :).
> Will it work for the 10% of people who browse without Javascript?[/color]

Point taken but let's not go overboard here. Whether it works for the
10% who don't use Javascript is moot. People in other language
newsgroups don't add disclaimers that their code won't work for people
that don't have the interpreter for their particular language.

My point is, it is FAR from impossible. Not only is it possible, but,
regardless that Explorer and Mozilla "are *not* the internet", they do
comprise about 90-95% of browser share, at least according to statistics
I viewed at w3schools.org a couple of weeks ago.

For the other approx. 15% (if you lump together
non-Javascript/non-IE/non-Mozilla) then a warning will have to suffice.
I never disagreed with that.

But to be able to provide a safeguard for the other 85% is eminently
possible, a *good* thing, and a possible solution to the OP's question,
which, after all, is the goal. Indeed, in a closed/intranet environment
where standards such as IE/Mozilla and acceptance of popups can be
dictated, my *constructive* suggestions can work up to 100% of the time.

[Richard Cornford]

Re: How to force submit if values change

George Jempty in <news:bCMZb.119 19$ld7.3506@big news3.bellsouth .net>
wrote:
<snip>[color=blue]
>... . People in other language newsgroups don't
>add disclaimers that their code won't work for people
>that don't have the interpreter for their particular language.[/color]

The situation is not comparable. While the majority of software
authoring can be done with a confidence in an appropriately supportive
environment (or range of environments) the browser scripting cannot.

Browser scripts for the Internet have to be designed and written without
even knowing whether the browser at the receiving end is capable of
executing scripts at all, let alone capable of supporting the features
any given script would like to use. Indeed with the majority of web
browsers incapable of executing scripts and a strong tendency for
individuals (and companies) to actively disable (or significantly
restrict) scripting over security and privacy concerns (or just because
they get fed up with the silly stunts that inconsiderate script authors
like to pull), it is even probably that every script will, at some
point, encounter an environment in which it cannot execute.

As that is the reality of Internet browser scripting, and this group has
a strong bias towards that particular application of javascript, the
consequences of a total or partial failure to execute is a major
consideration in the appropriate design of javascript.

But because achieving a script design that enhances a web page when
functional, but does nothing to detract from its content or usability
when it fails to execute is an extremely difficult task, less skilled
script authors will often prefer to ignore the reality. Citing any old
excuse; often bogus statistics but also a disinterest in users who
choose to execute their right to use any browser they like in any
configuration it supports.

So it is often necessary to remind contributors to the group that
appropriate script design is as important a skill in Internet browser
scripting as the ability to write syntactically correct, functional and
efficient javascript source code; if not more important.
[color=blue]
>My point is, it is FAR from impossible. Not only is it possible, but,
>regardless that Explorer and Mozilla "are *not* the internet", they do
>comprise about 90-95% of browser share, at least according to
>statistics I viewed at w3schools.org a couple of weeks ago.
>
>For the other approx. 15% (if you lump together
>non-Javascript/non-IE/non-Mozilla) then a warning will have to
> suffice. I never disagreed with that.
>
>But to be able to provide a safeguard for the other 85% is eminently
>possible, a *good* thing, and a possible solution to the OP's
>question, which, after all, is the goal. Indeed, in a
>closed/intranet environment where standards such as IE/Mozilla and
>acceptance of popups can be dictated, my *constructive* suggestions
>can work up to 100% of the time.[/color]

The desire to perform some sot of interaction with a server when a
browser is closed or navigated is very common and has been kicked around
a lot over the years and the running conclusion is that it cannot be
done reliably even on javascript capable/enabled browsers. Very simply,
asynchronous actions initiated in he onunload event are often not
completed (or even started) by the time the browser closes.

If the problem is as simple as getting a user to appreciate the need to
save changes before navigating away from a page, or closing the browser,
something as simple as labelling the form's submit button "save changes"
should go some way towards making it clear to the user that they are
required to actively participate in the process. A javascript
enhancement might, for example, switch the background colour of that
button to red as soon as the user changes something. Possibly that might
be extended to a more general visual indication of a change of status in
the contents of the form. Though visual indicators will not impact on
the users of text browsers or screen readers.

The only circumstances under which it would make sense to take responsib
ility for submitting changes away from the users would be when it could
be done with 100% reliability and operating over HTTP denies that
possibility even without the javascript issues.

Richard.

[Randy Webb]

Re: How to force submit if values change

Richard Cornford wrote:[color=blue]
> George Jempty in <news:bCMZb.119 19$ld7.3506@big news3.bellsouth .net>
> wrote:
> <snip>
>[color=green]
>>... . People in other language newsgroups don't
>>add disclaimers that their code won't work for people
>>that don't have the interpreter for their particular language.[/color]
>
>
> The situation is not comparable. While the majority of software
> authoring can be done with a confidence in an appropriately supportive
> environment (or range of environments) the browser scripting cannot.[/color]

I think his point, and I agree with him, is that you don't see
disclaimers in the ciwas group "This only works if the user hasn't
disabled it, and only if the browser supports it". Same goes for the
vbscript groups, where you don't see a lot of "Hey, this is IE only
stuff", etc..

I have always thought that the "it doesn't work if js is not present or
disabled" argument was an idiotic one. Yes, people (newbes) should be
aware that not everyone has it, or has it enabled, but to go way
overboard with it is just that - going overboard - and it seems to
happen a lot more in this group than others.

<--snip-->

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Richard Cornford]

Re: How to force submit if values change

Randy Webb <t9KdnUcV4fBWF6 bd4p2dnA@comcas t.com> wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> George Jempty wrote:[color=darkred]
>>>... . People in other language newsgroups don't
>>>add disclaimers that their code won't work for people
>>>that don't have the interpreter for their particular language.[/color]
>>
>>
>> The situation is not comparable. While the majority of software
>> authoring can be done with a confidence in an appropriately
>> supportive environment (or range of environments) the browser
>> scripting cannot.[/color]
>
> I think his point, and I agree with him, is that you don't see
> disclaimers in the ciwas group "This only works if the user hasn't
> disabled it, and only if the browser supports it".[/color]

We must be reading different ciwas's because I see quite a lot of posts
pointing out the limitations of CCS and circumstances where its being
disabled, or overridden by user stylesheets, will have consequences for
what an author appears to intend to attempt with it. But even then CSS
is just presentation so its removal will still always leave the HTML and
its contents available, if not necessarily very attractive.

Much of the time what is attempted with javascript goes well beyond
minor visual enhancements and the consequences of the inevitability of
its failure in some environments can impact seriously upon the results.
If posts on this group warn people that there is more to javascript
design that writing error free code then that strikes me as
demonstration of people taking a responsible attitude towards what they
do.
[color=blue]
> Same goes for the vbscript groups, where you don't see
> a lot of "Hey, this is IE only stuff", etc..[/color]

I don't bother with vbscript so I cannot say how responsible its
advocates are being.
[color=blue]
> I have always thought that the "it doesn't work if js is not present
> or disabled" argument was an idiotic one. Yes, people (newbes) should
> be aware that not everyone has it, or has it enabled, but to go way
> overboard with it is just that - going overboard - and it seems to
> happen a lot more in this group than others.[/color]

With a prevalent attitude that it is acceptable to author web sites by
finding any old copy and paste scripts, and jamming them into web pages
with no understanding of their mechanism and no regard for the
consequences, there are a lot of people coming here for what they
perceive as a quick javascript fix for their problems. Javascript isn't
that, Internet javascript authoring, with its requirement for a complete
and strategic design conception covering the spectrum of possible
execution (or not) environments, is probably one of the harder
programming tasks available.

If a superficially simple language and the absence of any need for
special authoring software results in anyone who wants to starting to
create browser scripts posting them here I can see no reason for not
pointing out to them that there is considerably more to the task that it
may at first appear and that script design is not only about writing
code.

And in the context of this thread, we know that triggering request to a
server in the onunload event is not reliable, and it should be fairly
obvious that giving the user the impression that their work has been
automatically saved for them when in fact it hasn't is not going to be
satisfactory. Better to make it clear to the user that in an HTTP
context they need to be expecting to actively participate in the saving
of their changes and seeing some sort of returned confirmation before
believing that anything has happened. Blind faith and a tolerance of a
percentage of guaranteed failure are not characteristics appropriate to
Internet browser scripting.

Richard.

[Grant Wagner]

Re: How to force submit if values change

Richard Cornford wrote:
[color=blue]
> If a superficially simple language and the absence of any need for
> special authoring software results in anyone who wants to starting to
> create browser scripts posting them here I can see no reason for not
> pointing out to them that there is considerably more to the task that it
> may at first appear and that script design is not only about writing
> code.[/color]

I think this is one of the biggest problems. I know several IT professionals
who regard Javascript as a "toy" language and that writing client-side
Javascript is "trivial". They are often surprised, and in some cases
offended to the point of becoming pig-headed, when I point out the problems
with code they have written. The reaction at that point is usually that
"Javascript sucks anyway" and they abandon what they were attempting to do.

Anyway, I just wanted to thank you for a couple of your posts on this
thread. I've cut/pasted a couple of your extremely well-thoughtout and
level-headed arguments and I'm sure I'll have opportunity in the future to
use them (with appropriate credit to you of course).

Again, I just wanted to say "thanks" for contributing to this group.

....Grant

[Randy Webb]

Re: How to force submit if values change

Grant Wagner wrote:
[color=blue]
> Again, I just wanted to say "thanks" for contributing to this group.[/color]

Ditto.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Richard Cornford]

Re: How to force submit if values change

Grant Wagner wrote:[color=blue]
> Richard Cornford wrote:[color=green]
>> If a superficially simple language ...[/color]
>
> I think this is one of the biggest problems. I know several IT
> professionals who regard Javascript as a "toy" language and that
> writing client-side Javascript is "trivial". They are often
> surprised, and in some cases offended to the point of becoming
> pig-headed, when I point out the problems with code they have
> written. The reaction at that point is usually that "Javascript
> sucks anyway" and they abandon what they were attempting to do.[/color]

That corresponds exactly with my experience, and occasional questions
posted to the group. It is a "toy" language until it bites back and then
it is broken language because it didn't turn out to be the toy that the
misconception made it.

Javascript's loose typing and dynamic nature, from the perspective of a
class-based language programmer, may seem to be concessions made for the
benefit of undisciplined amateur programmes. In reality they are
powerful features ideally suited to programming for the quicksand
environments of web browsers. Much harder to properly exploit than they
at first seem, and requiring at least as much discipline on the part of
the programmer to keep track of. In fact frequently a major stumbling
block for amateur scripters rather than being a way of avoiding exposing
them to issues.

I am not even sure a rigidly typed, class-based language would be up to
the task of browser scripting. I certainly would not want to attempt the
task in Java (the reflect package and Class class would get a good
workout along the way).
[color=blue]
> Anyway, I just wanted to thank you for a couple of your
> posts on this thread.[/color]

You are welcome (as is Randy).
[color=blue]
> I've cut/pasted a couple of your extremely well-thoughtout and
> level-headed arguments and I'm sure I'll have opportunity in the
> future to use them (with appropriate credit to you of course).[/color]
<snip>

That makes me wish I had put a little more time into proof reading them
:)

From the copyright perspective, you have my explicit permission to
reproduce them as you see fit (possibly including correcting any obvious
typos and grammatical errors).