Changing colour on textChanged - advice for best practice?

Targets Web
1

Hi all,

I wanted to add a nice touch to the user interface when entering a user email: If not valid format then text colour should be red, otherwise black. Rightly or wrongly, I implemented this in the textChanged event:

if  me.Text.IsEmpty then return

if App.isValidEmail(me.Text) then
  me.Style.ForegroundColor = color.Black
else
  me.Style.ForegroundColor = color.Red
end If

This calls App.IsValidEmail(email as string) as boolean:

var regex as new RegEx
regex.SearchPattern = "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"
return regex.Search(email) <> nil

This works in essence, but gobbles up characters when typing quickly - I presume there is some delay causing this. I guess I could put this in the FocusLost event, but it’s just a bit nicer seeing it in real-time… is this possible? Or is the general advice to do this on FocusLost?

Many thanks
Stam

2

Simplifying the textChanged event handler to

if  me.Text.IsEmpty then return

var regex as new RegEx
regex.SearchPattern = "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"

if regex.Search(me.text) <> nil then
  me.Style.ForegroundColor = color.Black
else
  me.Style.ForegroundColor = color.Red
end If

still results in gobbling up characters and incorrect behaviour in a WebTextField when typing quickly… Unless there is some way to mitigate this (other than typing slowly), I’ll have to forgo this running in TextChanged…

3

I’m afraid this is it.
You can either try to use FocusLost or create your own WebSDK control that runs your validation on the browser side.

4

Would it be possible to set up a WebTimer on the page with a very small Period (100 or so)? Place the validation code in WebTimer.Run and set RunMode to WebTimer.RunModes.Single. In your TextChanged event simply call Reset on your WebTimer instance.

Simply resetting the WebTimer in TextChanged should be fast enough to prevent gobbling up characters as someone types. Once there is a 100ms pause, the WebTimer.Run event quickly fires and performs the validation.

5

Xojo web is way to limited. It lacks client side behavior. If you implement the text change, almost every key press means all the text of the control is sent to the server then your logic goes to the client.

In the same PC, in another location your user will just close the page.

Same problem, focus goes to another control, event is sent to the server, user starts typing in other field and mid password sudenly the previous field changes. Do you remember the IE memes? Any app looks dumb whit those delays.

Any code runs in the server, same problem.

Best practice (in xojo), wait for the user to click SEND, make sure to autodisable the button, do all validations, Style changes and button enable in a single Sub.

6

Would things improve if WebTimer.Locations.Browser was set in the IDE?

I was thinking that a WebTimer placed on a page and set to Locations.Browser would fire on the client browser and was designed to update controls on a page, but I might be mistaken? I admit I might not fully understand order of events and where they’re sent in this situation.

7

I think it is worse, even if the timer fires in the browser, the code still runs in the server. It means an extra round trip:

  • Timer fires in browser
  • Browser sends Timer event to the server
  • Server reacts…
8

I did that - no difference, still gobbles up characters…

For now I’ve moved this to FocusLost, and it works OK-ish (just not as nice as happening in real-time, but will do). At least it stops saving invalid emails…

9

Understood and thank you for the explanation.

Since TextChanged still gobbles up characters, that highlights the statement that best practice would be performing validation after clicking Send (or FocusLost) and not in a WebTimer.

I’ll need to go back and check my code to ensure I haven’t made this mistake.

10

Be careful, Picture this:

  • User ends typing
  • User clicks Save
  • Focus lost is fired
  • On the same machine, maybe the server response arrives here and blocks the next event.
  • Save is fired
  • But in a real internet connection, it could arrive here when the broser already sent the save event
11

Sure - but there is a big red piece of text in the interface.

I should have mentioned that this interface is not for users, it’s for admin access when creating users so frivolous misuse is less likely - of course I don’t put anything past the admin team either, but the red text will stand out at least.