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.s ubmit(), 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.getEle mentById('isnew ');
lvIsnewV = lvIsnew.value
lvRepf = document.getEle mentById('repfr eq');
lvRepfV = lvRepf.value;
lvNotes = document.getEle mentById('NOTES ');
lvNVal = lvNotes.value;
lvDue = document.getEle mentById('dueda te');
lvDueV = lvDue.value;
lvNotComp = document.getEle mentById('NOTCO MP');
lvNCVal = lvNotComp.check ed;

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

lvDescrip = document.getEle mentById('DESCR IP');
lvDVal = lvDescrip.value ;
if (lvDVal == "") {
alert("Descript ion 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]

On Mon, 16 Aug 2004 16:57:41 GMT, John Kiernan <ki********@ver izon.net>
wrote:

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.

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail

[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="JavaS cript" 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=mouse test()></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/

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.s ubmit(), 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.getEle mentById('isnew ');
lvIsnewV = lvIsnew.value
lvRepf = document.getEle mentById('repfr eq');
lvRepfV = lvRepf.value;
lvNotes = document.getEle mentById('NOTES ');
lvNVal = lvNotes.value;
lvDue = document.getEle mentById('dueda te');
lvDueV = lvDue.value;
lvNotComp = document.getEle mentById('NOTCO MP');
lvNCVal = lvNotComp.check ed;

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

lvDescrip = document.getEle mentById('DESCR IP');
lvDVal = lvDescrip.value ;
if (lvDVal == "") {
alert("Descript ion 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;
}

[Grant Wagner]

John Kiernan wrote:

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

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[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
"Grant Wagner" <gw*****@agrico reunited.com> wrote in message
news:41******** ******@agricore united.com...

John Kiernan wrote:

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

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Yann-Erwan Perio]

John Kiernan wrote:

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(th is.form)">
</form>

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

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

[Yann-Erwan Perio]

Yann-Erwan Perio wrote:

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

Erratum :

function foo(frm){
var func=frm.onsubm it;
if(typeof func=="function ") {
if(func!=bar) {
frm.onsubmit=fu nction(evt){
func.call(this, evt);
return bar();
}
}
} else {
frm.onsubmit=ba r;
}
foo=function(){ };
}
Good night;-)
Yep.

[Richard Cornford]

John Kiernan wrote:
<snip>

<p><input type="submit" value="Submit" name="B1"
OnMouseUp=mouse test()></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="retu rn 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.

[Brian]

Michael Winter wrote:

If not, pay someone for answers. After all, you're getting our help
for free and you get what you pay for[1]. [1] Actually, with the quality of the regulars here, you're likely to
get better than what you could pay for.

That's my impression. I'm regularly shocked by the sort of advice
offered by those who get paid. That's not restricted to js, of course.
I've had professionals -- web hosting company tech support -- explain
that meta refresh is the proper way to redirect from an old address to a
new one. This was after I specifically requested 301 response from an
old domain to a new one. Egads.

By contrast, the regulars in comp.lang.*, comp.www.servers.* and
comp.infosystem s.www.authoring* groups provide very good advice.
Provided you can weed out the nonsense and put up with the irritations
of usenet. ;-)

"Usenet is like a herd of performing elephants with diarrhea
--massive, difficult to redirect, awe-inspiring, entertaining,
and a source of mind-boggling amounts of excrement when you
least expect it." --Gene Spafford, 1992
--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/