470,594 Members | 1,510 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,594 developers. It's quick & easy.

events get lost (from onBlur to onClick)


Hope somebody knows how to solve this one.

*The Situation*
A traditional situation where HTML form inputs are checked...

(if simplified then it would look something like this)

<form onSubmit="return checkWholeForm(this)">
<!-- other inputs -->
<input type="text" name="anInput" onBlur="dataCheck(this, ...)" />
<span id="error_anInput"></span>
<!-- other inputs -->
<input type="submit" name="btnSubmit" />

dataCheck validates the inputs value and if something is wrong, then..
document.getElementById('error_anInput').innerHTML = 'Error!'
or if data is valid then the content of span is removed.

The checkWholeForm function iterates through all elements on the form
and triggers onblur() for each input... leading to executing function
dataCheck (and so changing innerHTML of some specific span elements if

*The Problem*
If I have entered incorrect data to an input and hit the submit button
with my mouse (causing the onBlur event to be triggered just right
before onSubmit) then *occasionally* for some fields the onSubmit event
is not triggered because the onClick event is not triggered. :S

As there are actually quite many complex functions (tested and these
seem OK afaik) that are doing the checks then dowes anyboudy have a clue
what type of code might break this. I thought at first that setting
innerHTML to some value during onBlur disables all waiting events but as
this is happening occasionally (on some machines) I'm in doubt...

any ideas what to check? double declaration of function/variable names?
Not deleting some object after usage? ... anything?

Waiting for any ideas...

PS. http://eix.lap.ee/test/portali_js.html in the example *occasionally*
third field generates the error - remove any content from the field
and stright hit the submit (*with mouse* - to create onBlur and onClick
at the same time).

Thanks for any ideas...

Oct 5 '05 #1
2 5412
I would suggest avoiding using `submit` buttons altogether. If you have
JavaScript and all users must use JavaScript then set the onsubmit
event of the form to `return false`.

Create a regular non submit / image / ... with an onclick event that
fires a function. This function should do all the processing you need
and if everything checks out ok then execute

This probably will get around your issues with events.

As a side note, I would also suggest not firing onblur events to
validate your form fields. The way that I develop is that I have a data
structure (recordset of sorts) that stores all validation entries for
the page keeping the form elem names, the alias's (for alerts), and the
types of validations requred (Null, Null Warning, Date, Integer,
Percent, ...). When the onblur of the form fires it calls a function
that searches out the validation entries in the data structure. When
the form is submitted, it loops through entire data structure and runs
same validations (without executing onblur).

This method has been in my production env for 4 years now and still
running strong. I even keep a spreadsheet to store my form attributes
and the various validations requred and the spreadsheet generates the
JavaScript for me. I just copy and paste into the template.


Oct 6 '05 #2
> PS. http://eix.lap.ee/test/portali_js.html in the example *occasionally*
third field generates the error - remove any content from the field and
stright hit the submit (*with mouse* - to create onBlur and onClick at
the same time).

Javascript events... i figured it out but how could I solve it...
The thing is that occasions were these where the submit button at the
end of the page moved. Changing innerHTML abouve must be big enough to
make the bottom of the page move. So when clicking on the button the
onblur moved the button while the onclick event is published on the
location where button was rendered before.

Tricki :)

Thanks for reading... I made my point so if anybody should get stuck to
the same problem... the problem is known and could be avoided...
To boldly go where no one has gone before
Oct 6 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Sandman | last post: by
4 posts views Thread by Gaz | last post: by
1 post views Thread by Christoph | last post: by
2 posts views Thread by Robert Bravery | last post: by
1 post views Thread by swethak | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.