Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Tricky OnExit and SetFocus problem.
Hi All,

I have a very tricky problem I'm unsure how to solve.

I have two IWEdits, IwEdit1 and IWdit2. Each has an OnExit event. The events are similar:

in IwEdit1.onExit: if IwEdit1.text = '' then IwEdit1.SetFocus; and
in IwEdit2.onExit: if IwEdit2.text = '' then IwEdit2.SetFocus;.

IWEdit2 is next logical field after IWEdit1 in the Taborder, and when both IwEdits are empty, and I tab out of IWEdit1, then the cursor starts an endless jump between the two IwEdits, because:

When exiting IwEdit1, the cursor is first moved to IwEdit2. Then the code realizes IwEdit1 is empty, and Setfocus moves it back to IwEdit1. However, as the Cursor already was in IwEdit2, IwEdit2.OnExit realizes the Cursor has left, and as IwEdit2 is empty, IwEdit2's SetFocus, moves it back to IwEdit2. And so IwEdit1.OnExit takes over again and so on and on and on....

How can I break this ?

In VCL, in Edit1.OnExit, I would disable Edit2's OnExit event before executing Edit1.Setfocus, and enable it again after, so that when Edit1.Setfocus pulls it out of Edit2, Edit2's OnExit event is not fired. How can I do something similar in InterWeb with IwEdits ?

You can probably make it work by changing the logical switch put at the beginning of "onexit" for the others "edit" components. These switches will decide that these codes will end immediately, without execution. However, I would advise you against doing this. The user, when they see that they have no control over the position of the caret, will be pissed off and will give up filling out the form. You'd better give a different color for empty "edit" components and different for correctly filled ones. Then just give a hint that the form could not be sent due to missing fields.
Hi MrSpock,

Thanks for your input. Checking for an empty field at exit and return the cursor to the field with SetFcus, was to make sure a field is filled in before sending the form. But as you say, it also means the users do not have any control, and in fact I had it set up so that if a field content was not correct, setfocus was called to return the cursor to the field. It means it is not only when the field is empty, also when the contents is false.

So I have done as you suggested: keep a list of booleans, one for each field, being set in the OnExit to true when everything is ok, and to false if, for what ever reason, the contents is false (empty, wrong, whatever). And if a field is false I set the color to red with white font, to easily spot which field is not correct. In the OnKeyDown I reset the color to standard.

And finally, at the time to send the form (save the data) I check to see that all booleans in my list is true. And if not, I abort saving and place the cursor at the wrong field.

Also I have enhanced the function with a message field, telling the user the reason for why a field is red, and that too, is removed at the first keydown.

It might not be 100% fail safe but as far as I can test, it works, and allows the users to fill in the field in any order they want.

I'm sure that if I had a little more JS experience, I could do most of it directly in the client. As it is now, I do it on server side, though with the OnAsyncXXXX events.

The problem the way I see it is the whole concept. In Windows it is not recommended that you forbid an user to leave a control (yes, I know that people do it nevertheless). The problem is worse when you deal with the browser because the onBlur event in a browser doesn't happen exactly as OnExit on Windows.

Instead of trapping the cursor inside the edit box, it is better to give the user other visual indication that they need to fix something, like filling that edit box.

WebApplication.ShowNotification() method is great for it. You should try it out. It gives the user a highly visible feedback but doesn't interrupt their workflow at all.

Forum Jump:

Users browsing this thread: 1 Guest(s)