Submit/Firing Order, Take 2

[John Kiernan]

Hey JavaScript gurus...

I'm going to try this again. I haven't gotten as much help as I have advice
on style<grin>. I appreciate (having programmed in other languages for
quite a while) that everyone has their own opinion on HOW things should be
done. However, if it does not comes AFTER helping me figure out my problem,
please... (fill in your own polite way to say 'save the bandwidth').

I have code in a MouseUp of my save button (yes, technically it should go
into the 'OnSubmit()' of the form, but I don't want to do that, because I'm
already hacking one pre-packaged class (in VFP) and I don't want to be
hacking a second). There is NO "OnSubmit" on the form itself (to pre-answer
a question).

On everything else in the JavaScript function I'm talking about, if I trap
for an input error, I return a 'false' and the form doesn't submit. If I
return a 'true', the Form submits just fine.

However, on the last part of the routine utilizes a 'Confirm()' -- within an
IF statement. As per a hint from someone here, I changed it from utilizing
a variable to simply returning a true or false. However, it doesn't work --
in the same way the variable didn't work. If I return a false, the form
doesn't submit, but even if I return a true, the form doesn't submit.

Using deductive reasoning in that I have the Confirm() within an IF
statement (and it's the only thing within it) and the whole thing works if I
don't enter the IF and it DOESN"T work if I do, I think I can narrow the
problem down to the Confirm().

I would simply put in a hard coded document.form.submit(), except that
doesn't work with the back end VFP stuff I have interpreting the return form
variables.

Can anyone else duoplicate this or help!?!?

I can't imagine someone else sometime hasn't put in a confirm() in this way?
Could it be? Code pasted in below...

Lost in Santa Monica.... (HELLLPPPP!!!)

-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends

function cliservsave() {
lvIsnew = document.getElementById('isnew');
lvIsnewV = lvIsnew.value
lvRepf = document.getElementById('repfreq');
lvRepfV = lvRepf.value;
lvNotes = document.getElementById('NOTES');
lvNVal = lvNotes.value;
lvDue = document.getElementById('duedate');
lvDueV = lvDue.value;
lvNotComp = document.getElementById('NOTCOMP');
lvNCVal = lvNotComp.checked;

if (lvNVal == "" && lvNCVal == true) {
alert("If Not Completed, Notes MUST be entered.");
return false;
}

lvDescrip = document.getElementById('DESCRIP');
lvDVal = lvDescrip.value;
if (lvDVal == "") {
alert("Description Cannot be Blank.");
return false;
}

if (lvNCVal == true && (lvDueV !== "" && lvDueV !== "01/01/00") ) {
alert("If Not Completed, Due Date must be Blank.");
return false;
}

if (lvIsnewV == "true" && lvRepfV !== "None") {
return confirm("Are you sure you want to generate multiple records?")
}

return true;
}

 

[Michael Winter]

I'm going to try this again. I haven't gotten as much help as I have
advice on style<grin>. I appreciate (having programmed in other
languages for quite a while) that everyone has their own opinion on HOW
things should be done. However, if it does not comes AFTER helping me
figure out my problem, please... (fill in your own polite way to say
'save the bandwidth').

Sorry for the slap on the wrist, but...

I'd like to take a moment to point out that this group is a forum for
discussion. It is not a help desk. If the discussion happens to coincide
with providing you, the poster, with an answer, and it usually does,
great. If not, pay someone for answers. After all, you're getting our help
for free and you get what you pay for[1].

[snip]

On everything else in the JavaScript function I'm talking about, if I
trap for an input error, I return a 'false' and the form doesn't submit.
If I return a 'true', the Form submits just fine.

Have you tested this in more than one browser? Did it make a difference?
Answering those questions won't really help, but it might help others in
future.

As the test that prompts this confirmation doesn't depend on anything
other than the value of two controls, have you thought of moving the
confirmation to change events that are placed on the controls in question.
That would mean no interference with the mouseup event, and no possibility
of invoking browser bugs. It would be best to make sure that the
confirmation only occurs once.

Of course, the better thing to do is place an intermediary step on the
server that asks for confirmation so that JavaScript-less users don't
bypass it unknowingly. Of course, if this isn't for the Web, there's no
need for that.

[snip]

Good luck,
Mike


[1] Actually, with the quality of the regulars here, you're likely to get
better than what you could pay for.

 

[John Kiernan]

Points taken...

I think at this point, this thread will become more of a 'heads up' to
everyone, because I'm pretty sure the answer is:

"Don't put anything in a MouseUp (or MouseDown) event that comes
immediately before a submit()!"

Why do I say that? Simple...

I made an HTML form with ONE element in it, a submit button. On that button
I placed a OnMouseUp() call to a .js file with only a call to a confirm()
box. When I ran it, it subverted the submit() no matter what the user
chose. I then took out the confirm() and put in an alert(). It also
achieves the same thing (regardless of what the function returns).

Answer: don't use an Alert() or a Dialog() on the button that performs the
submit()!

Code provided below for forensic anaylsis...

-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends

HTML Source:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<script language="JavaScript" src="c:\test.js"></script>
</head>
<body>
<form action="http://www.nytimes.com/pages/aponline/news/index.html"
method="POST">
<p><input type="submit" value="Submit" name="B1"
OnMouseUp=mousetest()></p>
</form>
</body>
</html>

JS Source (test.js):
function mousetest() {
// alert("This is a test");
// return true;
return confirm("Are you sure you want to generate multiple records?")
}

 

[Alberto]

You'd post the code of the form tag, John.

A few already stressed this to you. My guess is that you don't have an
action property specified in the form tag. Maybe a naive guess but we'd
really need the form html tag and the button html codes too, as they appear
in your page, to make a more valid guess.
A confirm retgurning false should not submit the form. Yet it depends too on
how your form tag is crafted.

Also, have you tried a simpler thing:

function cliservsave(){
alert("hallo"); return false;//FALSE
}

then
function cliservsave(){
alert("hallo"); return true;//TRUE
}

then
function cliservsave(){
return confirm("hallo"); //TRUE or FALSE
}

This trivial debugging may seem terribly naive and yet it is the only thing
that can tell you whther you have a problem
1) in the form tag
2) in something else than the return statements - if those simple snippets
work on _your_platform, then the problem is _not_ in the returns. It is an
important blueprint to ascertain you sede why those trivialities can be
important.

keep us posted, ciao
Alberto
http://www.unitedscripters.com/

 

[Grant Wagner]

Points taken...

I think at this point, this thread will become more of a 'heads up' to
everyone, because I'm pretty sure the answer is:

"Don't put anything in a MouseUp (or MouseDown) event that comes
immediately before a submit()!"

Why not use an onclick event?

Answer: don't use an Alert() or a Dialog() on the button that performs the
submit()!

<form name="myForm">
<input type="submit"
name="mySubmit" value="Go"
onclick="return confirm('Do you really want to go?');">
</form>

Works just fine on Netscape 4.78, IE6SP1, Opera 6.05, Opera 7.54, Mozilla 1.7.2
and Firefox 0.9.3

 

[John Kiernan]

Well... I *thought* this was the answer! OnClick() indeed worked... except
it submits() no matter what choice is made (the opposite of the original
problem)!

I am using -- by the way -- IE and all my users (without exception) use IE.
The fix only has to work in IE, if it's any help.

Still stumped...

I was looking around that somewhere there was talk about 'Send' being
disabled... anybody know anything of that?

Thanks for everyone's help!

-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends

 

[Yann-Erwan Perio]

I have code in a MouseUp of my save button (yes, technically it should go
into the 'OnSubmit()' of the form, but I don't want to do that, because I'm
already hacking one pre-packaged class (in VFP) and I don't want to be
hacking a second). There is NO "OnSubmit" on the form itself (to pre-answer
a question).

I'm just coming back from holidays and didn't read your previous thread,
but ISTM that onsubmit really is what you want Wouldn't your problem
be solved by something like:


<form action="foobar">
<input type="submit" onclick="foo(this.form)">
</form>

<script type="text/javascript">
function foo(frm){
var func=frm.onsubmit;
if(typeof func=="function" && func!=bar) {
frm.onsubmit=function(evt){
func.call(this, evt);
return bar();
}
} else {
frm.onsubmit=bar;
}
}

function bar() {
return confirm("Are you sure?");
}
</script>


HTH,
Yep.

 

[Yann-Erwan Perio]

function foo(frm){
var func=frm.onsubmit;
if(typeof func=="function" && func!=bar) {
frm.onsubmit=function(evt){
func.call(this, evt);
return bar();
}
} else {
frm.onsubmit=bar;
}
}

Erratum :

function foo(frm){
var func=frm.onsubmit;
if(typeof func=="function") {
if(func!=bar) {
frm.onsubmit=function(evt){
func.call(this, evt);
return bar();
}
}
} else {
frm.onsubmit=bar;
}
foo=function(){};
}


Good night;-)
Yep.

 

[Richard Cornford]

John Kiernan wrote:

<p><input type="submit" value="Submit" name="B1"
OnMouseUp=mousetest()></p>

<snip>

The string value provided for an event handling attribute in HTML is
used by the browser to create a function that is assigned to a property
of the corresponding element within the DOM. Disregarding any provision
of custom scope chains that may be made by the browser, the above
onMouseUp handler is equivalent to:-

document.forms[0].elements['B1'].onmouseup = function(){
mousetest();
}

- executed with javascript. Thus the function object that represents the
event handling method of the submit button is a function that calls
another function, but returns no value. As a result it doesn't matter
much what the - mousetest - function returns as the event handler is not
passing that value on. It cannot cancel the event (unless the
proprietary returnValue property of the event object were set (on IE))
and so whatever default action follows from the event will happen.

A more viable formulation would be:-

OnMouseUp="return mousetest();"

- so the value returned from - mousetest - is also returned form the
actual event handler. (note that the attribute value should be quoted as
it contains characters that are not allowed in an unquoted value
(according to the HTML specification). Validating the HTML would have
pointed that out, and valid HTML is a considerable aid in easy and
reliable scripting as it results in a consistently structured DOM that
is not subject to the vagaries of HTML error-correction.)

Richard.

 

[John Kiernan]

AHA!!!!!!!!!!!!!!!!

No more calls!!! We *have* a winner!!!

Thank you Richard! Thank You! Thank You! Thank You! Thank You! Thank
You!

The answer was I need to do what Richard said:

OnMouseUp="return mousetest();"

Instead of what I was doing:
OnMouseUp="mousetest();"

It was running the function, but not RETURNing the value I was sending
back!!!!

(Even though I'm a novice to JS, I really should have known better!)

Thanks again to all who answered....

-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends

John Kiernan wrote:

<p><input type="submit" value="Submit" name="B1"
OnMouseUp=mousetest()></p>

<snip>

The string value provided for an event handling attribute in HTML is
used by the browser to create a function that is assigned to a property
of the corresponding element within the DOM. Disregarding any provision
of custom scope chains that may be made by the browser, the above
onMouseUp handler is equivalent to:-

document.forms[0].elements['B1'].onmouseup = function(){
mousetest();
}

- executed with javascript. Thus the function object that represents the
event handling method of the submit button is a function that calls
another function, but returns no value. As a result it doesn't matter
much what the - mousetest - function returns as the event handler is not
passing that value on. It cannot cancel the event (unless the
proprietary returnValue property of the event object were set (on IE))
and so whatever default action follows from the event will happen.

A more viable formulation would be:-

OnMouseUp="return mousetest();"

- so the value returned from - mousetest - is also returned form the
actual event handler. (note that the attribute value should be quoted as
it contains characters that are not allowed in an unquoted value
(according to the HTML specification). Validating the HTML would have
pointed that out, and valid HTML is a considerable aid in easy and
reliable scripting as it results in a consistently structured DOM that
is not subject to the vagaries of HTML error-correction.)

Richard.

 

[Alberto]

This depends on the fact that like, if I am not mistaken Michael told you,
a few very good guys loiter here
No I don't surreptitiously put myself in the pack LOL, but it is always
BEAUTIFUL to see constructive answers that lead to sove a problem fo a
person. I like when this happens, no matter whose was the answer.

if you consider how good the group can be when persons mind only to answer
questions and not to make silly rebuttals (in the past happened), you really
realize that the quality, also human here, can be interesting. Persons that
fought with javascript for years pop in here N ever dismiss these guys,
all of a sudden can make the difference lol.

And now say thank you again to Richard - *joking*

ciao, good luck!
Alberto
http://www.unitedscripters.com/

AHA!!!!!!!!!!!!!!!!

No more calls!!! We *have* a winner!!!

Thank you Richard! Thank You! Thank You! Thank You! Thank You! Thank
You!

The answer was I need to do what Richard said:

Instead of what I was doing:
OnMouseUp="mousetest();"

It was running the function, but not RETURNing the value I was sending
back!!!!

(Even though I'm a novice to JS, I really should have known better!)

Thanks again to all who answered....

-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends


news:[email protected]...

(snip)

 

[Richard Cornford]

John Kiernan wrote:

The answer was I need to do what Richard said:

Instead of what I was doing:
OnMouseUp="mousetest();"

It was running the function, but not RETURNing the
value I was sending back!!!!

<snip>

It was more 'an answer' than "the answer", in the sense that it
addressed a critical flaw in the original implementation. The other
suggestions made in relation to this question are still very valid,
particularly where they question the choice of event handler. If you use
a onmouseup event you are creating something that is pointing device
dependent. That would be in direct opposition to the recommendations of
the Web Content Accessibility Guidelines, where it is recommended that
functionality should be device independent (and so may have legal
implications in some jurisdictions/contexts).

However, mouse centred functionality is probably not a good idea in any
case. While it seems common for individuals who almost exclusively use
the mouse themselves for this type of task to assume that everyone else
does likewise, in practice individuals interact with computers in very
varied ways, depending on their circumstances and experience. For
example, it was my observation that numerous colleagues who had been
issued with IBM laptops found the pointing device on that machine so
inconvenient that they learnt all of the keyboard shortcuts, and having
learnt them they used them on any computer, and individuals who can
touch-type also appear to be significantly more inclined to be using
keyboard navigation.

Whatever you are doing the chances are good that at some point it will
be used by someone who uses the keyboard to interact with the browser
(entirely or in part) and when they do they will bypass your onmouseup
event handler.

Suggestions that - onclick - might be a better handler are valid, as it
is usually triggered by keyboard activation in addition to with the
mouse, but in my opinion the - onsubmit - handler of the form element is
the ideal place to be validating form content, and cancelling the
submission if need be. It has the advantages of being very well
supported, and intercepting attempts to submit a form by any means or
device (with the exception of code directly calling the form's -
submit - method, but that is always a bad idea).

The - onsubmit - handler has a direct relationship with the action that
is of interest in form validation.

Richard.

 

[John Kiernan]

Dear Richard (et al) -
Yes, you're all right that if this was a public application, I should be
flogged in the public square for this. However, it's a private, company
wide system (accessed by nurses who work for the company, often from home
and at various 'homes' for the disabled).

As a result, we have the ability to dictate certain things, like they HAVE
to use IE (for the specific DHTML we use). We use a dynamic (rights driven
and built) JavaScript menu navigation system -- so if you don't have
scripting turned on, you ain't doing nuthin'.

As the script is an adjunct to the server side, which has a mirror of the
validation, I'm just trying to cut down on the traffic and 'round tripping'
by validating on the client.

As a geek in other areas -- and one who posts and monitors other boards
that help newbies in my area, I have noticed (and am guilty of it myself
some times) that we geeks tend to want show our knowledge and great brains
more than answer the question as asked. As a result, the poster (me, in
this case) has to come back again and again to 'explain himself'.

As I said... I am as guilty of this as anyone, but I -- for one -- am
going to try to be more cognizant of this in the future.

Thanks again Richard!
-- John Kiernan, KierPro Associates
Custom VFP/Accounting Programming
and Web interfaces
VFP and/or SQL back ends