I have an onChange trigger (a Maintain trigger) on a field and a button with an onClick trigger (also Maintain) on it.

When I change the field value and then immediately click on the button I get the onChange trigger fired but the onClick never does. In theory both should fire, correct? If so in which order?

J.

This message has been edited. Last edited by: John_Edwards,

This is going to be a timing issue. I am assuming that you are making a change to the field and tabbing out of it? That will trigger the onchange event. You say that this is a Maintain event, so at this point control is being passed to the server. When the action on the server is done, the form refreshes and is redisplayed.

If during the time that control is being passed back to the server, you click on another object on the form, that is going to be ignored. The form does not have control. The server does. The form refreshes and the click is forgotten.

The only thing that may be different would be if the button click is a JavaScript event. Then it may fire as well.

Mark

The user is changing a value in an edit field and clicking on the Save button.

My only thought on this is that I can capture the name of the item that currently has focus and send that to the Maintain case. If it's the Save button then perform the save routine after the data-update routine. This of course assumes that the Save button is the location that currently reports as having focus.

I avoid Maintain triggers whenever I can but this screens much tougher than most. A whole bunch of autofill happens on it.

J.

You could compare the current value in the edit box with the original value when the user clicks SAVE and perform some action before you save the data.

Mark

I need the onChange trigger to be there one way or the other.

I'm considering using a pop-under to populate the values loaded by the current onChange trigger. That lets me weasel out of one of the two Maintain triggers. In the button trigger I can do what you say -- compare and perform both maintain routines if need be. It's a lot of work for an error condition that wasn't discovered for four years. But now that they know it's there they'll want it changed.

J.

Huh. Well I have everything in js triggers and I'm getting the onChange to process but not the clicked. It may be a limitation in IE.

I have a semaphore between the two to make sure the data in onChange processes prior to onClick and it's not setting off its message. So onClick is just being left unrun.

Huh.

J.

I am checking with programming. This just may be a limitation on how many triggers can fire.

Programming has confirmed my suspicions. After the change trigger fires, and we go to the server, when we return to the form, we have effectively posted a new form. The click trigger is just lost.

If you need more than one server event to happen, could you do:
OnChange event:
Perform case1
Perform case2

This way, Maintain makes sure that both events happen on the server and no other form interaction needs to occur.

Mark

Sorry Mark, I wasn't detailed enough in my reply. I'm all JavaScript now. The first trigger executes a Focexec call that backfills fields on the main form. That is, there's no IWCTrigger command and the Maintain page does not go to the server. Everything occurring in the Maintain page for the onChange trigger is happening in JavaScript.

The second trigger, onClick, is JavaScript as well. It has an IWCTrigger call at the end, but it can only execute the Maintain call if the prior trigger has completed its full action.

This may not be IB's problem. IE may be the culprit in this one. I haven't had a chance to write an ultra-simple example to test it yet and I'm at a different client today and won't get back to it until Thursday.

J.

Alright, this was a royal pain in the *** but I figured out how to work the problem. Here's the synopsis --

onChange is a junior trigger.

It's a browser thing. onChange cannot detect current document focus, cannot stack with other triggers. It essentially barges in on the execution thread and cancels everything attached to other widgets that was due to follow. That's why I was losing the onClick trigger execution. In my case I really need onChange to be where the work is done because it's a relatively complicated task that I don't want to fire via onKeyPress or even onBlur since the user passes through the field at the startup of the screen. It's a field of data that is auto-populated on startup so it doesn't change very often. But when it does it's generally followed immediately with the Save button. So there's one use-case that bangs right on this problem and all the rest need it to be out of the way.

Now, onBlur is a full blown deluxe trigger. I can detect screen state in onBlur, including document.activeElement. And it will fire after onChange for the same element. So I created an onBlur trigger --

  
if (document.activeElement.id == 'btnSave')
    OnbtnSave_Click(); 

With this in place the onChange fires when it's supposed to, then I manually kick off the Save request only when the user has "focused" on the Save button at the bottom of the screen. A little klunky, but I think "a little klunky" has been Internet Explorer's unofficial slogan since Windows 95.

J.