Onchange dosen't fire

try using the "onBlur" event instead of "onChange".

I need to use the onchange.
Using the onblur will invoke the method every time, even with no change was done, in the matter of preformances it's bad.

try using onBlur and onFocus together.

and let them call a custom onchange function created by you.

If I'll decide to change the current code, I'll go with using the onblur method, since it's much easier then any other implementation.

The solution I'm looking for is how to invoke the onchange when I change the value using script.
(without getting into a loop of event firing)

Is this what you meant, Lexxwern?

<input type="text" onFocus="this.changed=true"
onBlur="if (this.changed) formatData(this)">

Michel

Michel,
Using your solution is pretty much same as using just onblur since the onblur will always invoke after onfocus occured so the flag is not very usefull and it will not filter unchanged values.

I'm looking for a solution that can help me using the onchange (or alike) method.

onChange isn't a supported method of a text box.

Try using onKeyPress instead?

Yes it is.

So it is!!!

onChange

Runs when the focus leaves the input box and the input box value changes

IE 3.0

NN 2.0

sorry guys, but I've always used the onKeyPress as this was more useful for me.

It's an Internet Explorer bug. Your script works as intended in NS 6.0, and if you use the mouse in IE the onchange event fires correctly.

Use the onblur event, and then only perform the calculation if the value have changed.

<SCRIPT>
var lastcallStr = "";
function formatData(obj) {
     if (obj.value != lastcallStr) {
          //do stuff
          alert('Function was activated');
          obj.value="Now Retype '1'";
          lastcallStr = obj.value
     }
}
</SCRIPT>
Type in '1', and click Tab (for bluring and onchange invoking)<br/>
<INPUT TYPE="TEXT" onblur="formatData(this)" value="" style="WIDTH:200px">

neat^^

Rohde ,
I'm rejecting your answer because you it is not too nice to suggest an answer when others have suggested the same before.

The approach your mentioning is generally same is what micheal or lexxwern  suggested.
The intresting thing here that you are suggesting it's a bug, have you found it documented somewhere ?

I will close the question for the link to a documentation of this bug.

Oh, and Rhode try reading :
https://www.experts-exchange.com/jsp/cmtyQuestAnswer.jsp


And thanks for your help again.

I can tell that it is a bug simply by testing it in the browsers. When something doesn't work as it should, it's a bug (MS might disagree though :)

(Btw: I tried to summarize the other answers and make them easier to grasp, since you didn't seem to accept the others. It wasn't simply an attempt to "steal" points).

Summarising is fine, as a comment.
Questioner does not need to accept any comment until the discussion seems to be over.

Michel

Sorry to be off topic here, but there are points awaiting your comments, avner.
https://www.experts-exchange.com/jsp/qShow.jsp?ta=javascript&qid=20294625
Moondancer - EE Moderator

Hmmm..
Any suggestions how to close this question ?
Who wants the points ?
-Avner.

Well.... Michel, I'm not using onblur because I don't want to have any unneccesery processes taking place.
Rebuilding the whole input field on every change... I belive it's far more complicated for the JS engine, isn't it ?

It works so who cares? It is not a big deal I guess unless IE has a problem if there are hundreds of fields to "push down" It is on a field to field basis so the user does not see it.

Michel

Basically you are right. Since we have a very complicated web-application with far too much JS and we ancouter memory leaks with IE, I am trying to reduce all CPU usage.

But I guess I won't have a clean solution.

Now for question closing issue , ideas ?

If you do not want to use my solution which does what was required, then I suggest you asked the question to be PAQed and your points returned since none of the suggestions solved your problem to your satisfaction.

Alternatively send me the page at michel@irt.org, perhaps I can see some reductions.

Michel

although the solution dosen't fix the onchange problem from perfromances point of view, it does overcome the onchange bug/wrong implementation.

Myabe you can try other events such as onKeyPress or onKeyUp.

From the better late than never files...
The following is a more DOM compliant way of
compensating for the mentioned Microsoft bug.
Evidently, clones are not quite identical, ha ha.

<FORM>
<INPUT type='text' name='foo' value='Mom' onChange='changeNoted(this)'>
</FORM>
<SCRIPT type='text/javascript'>
function changeNoted(inputElem) {
    if (!inputElem.value) {
        inputElem.value = 'Dad';    // all we should need, but for IE...
        var cloned = inputElem.cloneNode(true);
        if (cloned.value=='Dad')    // Opera clone is fake (.value is 'Mom')
            inputElem.parentNode.replaceChild(cloned, inputElem);        
    }
}
</SCRIPT>

Csaba Gabor
only tested on IE 6 and Opera 7.23
Note: this method introduces orphan nodes into the DOM

I do not agree that's a bug. More like a safeguard.
Think about it:
when you change contents onChange() event fires.
inside onChange() event handler you change contents again.
That should trigger another onChange() even, and you will get into endless loop, which will cause stack overflow.

As far as IE concerned, the value of your textbox is still '1', that's why onChange event doesn't fire when you type '1' again - nothing has changed.

Your argument is not an argument against onChange firing upon a user
initiated event - only an argument against firing onChange when the event
is programatically initiated.  And as such it is reasonable.

But it does not apply to the user initiated events.  There is no danger of
stack overflow since programmatic change doesn't lead to onChange
firing.  So I do not find your argument compelling in opining that the
original behaviour described is not a bug.

Csaba Gabor from Vienna