Is there an equivalent of TextField.LostFocus on iOS

Hi everyone,

In my desktop apps, I like being able to use TextField.LostFocus to process user input because I think it’s a fairly unambiguous way of saying “yep, they’re done editing that field, now I can validate it and do something helpful with the contents”.

On iOS, we don’t seem to have the concept of a control having focus. iOSTextField does have states that I’d expect to work similarly to focus on a desktop app (i.e. it’s gone from having an insertion point in it and accepting input from the software or hardware keyboard to a state where the insertion point has gone away and the keyboard is hidden) but I’ve yet to work out how to fire events based on that. iOSTextField.TextChange will fire a lot when typing into a control, and I don’t necessarily want to validate and save data on every keystroke.

I know that I can use iOSView.Deactivate or a toolbar button labelled “Done” or “Save” to process user input, but there are cases where I’d want to process it before leaving the view.

Has anyone found a workaround for this, or have any bright ideas about alternative ways to tackle the problem?

There is, but you got to use a declare. See isFirtResponder in the wrapper

Which tells you if a text control has focus and displays the keyboard. You could use a timer to monitor that condition.

Also, see SetFocus and ClearFocus.

I see two possibilities, but both include extensions like libraries or plug-ins resp. declares. You can catch the didEndEditing or ShouldEndEditing event of UITextField (, or you could install a NotificationCenter and listen for the UIKeyboardDidHideNotification.

Hehe, and while I was thinking about writing a line like “But I wouldn’t be surprised if someone like Michel has a much easier solution” – q.e.d.!

IsFirstResponder would be a “flag” and you’d have to check it yourself
while didEndEditing is an event

[quote=242160:@Dave S]IsFirstResponder would be a “flag” and you’d have to check it yourself
while didEndEditing is an event[/quote]

Indeed. But for the moment, I am afraid that is all we have. Unless a good heart creates a declare to implement the events.

Jason Tait filed a feature request back in November 2014 for GotFocus, and Christian Schmitz added it would be nice to have LostFocus as well.

It is not even ranked yet. Add points if you want : <>


Thanks, everyone. Michel, I’ve added 150 points to that case :wink:

iOSLibTextField (see link above) has all the events. Drawback is, of course, you’d have to use a custom control instead of a normal Xojo textfield.

Congratulations, Ulrich. That is a beautiful work.

Thanks a lot, Michel. Basically only what Apple provides.

Hello Ulrich ,
We are developing an iOS Application .
We have used iOSLibTextField .
But we are facing problem while editing iOSLibTextField such that if text field got focus then keypad overlaps that textfield if its position lies in bottom.
So we can not see textfield which is currently being editing .
Is there any solution for this ?

Hi Nikita,
not from the Textfield itself, but yes: You should use the NotificationCenter to alert you on keyboard-related events, especially UIKeyboardWillShow and …DidHide. Their userDictionaries contain the size of the keyboard which you can use to either scroll your textfield or resize the main view. See

Let me know if you need further information.

It is automatic with iOSTextFields.

Can you please explain in detail how it will be achieved as we are not familiar with ios .

If instead of iOSLibTextField you use the standard iOSTextField, it will automatically push up when the keyboard is present.

We have also used iOSTextField for some forms,But we have changed iOSTextField to iOSLibTextField because we needed to implement lost focus event which is not present in case of iOSTextField.So for such fields we need to resize view when editing begins.

Well, you could use XojoiOSWrapper as suggested above with iOSTextField, in the second post of this thread.

Can we use iOSLibKeyboardEventDictionary to get keyboard size?

Sorry for letting you wait, Nikita! I’m a bit ill currently, so yesterday I was too drowsy to reply.
Yes, basically the KeyboardEventDictionary is what you are looking for. Wow, I even forgot I created one! :smiley:
Looks like you’re on a good path. In case others are looking for this solution too, here a rather lengthy explanation:

It would probably be better to subclass iOSLibTextField so that each textfield gets the notifications itself. It should only react if it is the current responder. I am lacking a bit of focus myself today, but I’ll try to extend the class ASAP.
If you want to try: You’ll find examples on how to use the SharedNotificationCenter to install block methods throughout the library. An example is AppleWindow/AttachNotificationCenter. Basically, you register the Notification name and the AppleBlock that should fire when the notification occurs. The register method delivers a handle – a NotificationObject –, that you should buffer and use to deregister when the control closes.

As an example:
Give your textfield subclass a Property NotificationObjects() As AppleNotificationObject
In your constructor, add a similar method like the AttachNotificationCenter method from AppleWindow after super.constructor.
In this method, you should register each Keyboard notification (see AppleWindow again where the notification names are constants), for example:

Dim WillShowBlock As new appleBlock (addressOf YourMethodThatshouldFireWhenKeyboardShows) NotificationObjects.Append AppleNotificationCenter.addObserver ("UIKeyboardWillShowNotification", me, AppleOperationQueue.MainQueue, WillShowBlock)

YourMethodThatshouldFireWhenKeyboardShows must be a method that takes a Ptr as input value, and as first action it should convert the ptr to an AppleNotification. Let’s say you named the input ptr simply p:

Dim Notification As New AppleNotification(p) Dim userDict as iOSLibKeyboardEventDictionary = iOSLibKeyboardEventDictionary.MakeFromPtr(
BeginFrame and EndFrame will give you the NSRects of the keyboard.

Do so with all the Keyboard notifications you want to handle. WillShow and WillHide or DidHide should be the most relevant ones.

When the control closes, iterate over the NotificationObjects:

AppleNotificationCenter.RemoveObserver (currentObject)

There is no need to install AppleNotificationCenter or create it. It is a soliton that creates itself once it is called.

Thanks Ulrich for your reply .
We will try to implement this.
One more question for you is can we use iOSLibScrollView for this purpose ?so that we can scroll up view while typing.

The current version of iOSLib has no scrollView. I did not work on it after Xojo incorporated a native control. Are you using an old version of the library?