iOS Question Hide keyboard in MessageComposer?

[JackKirk]

Is there any way to turn keyboard off when showing an SMS message with MessageComposer?

Maybe with NativeObject?

Thanks...

PS - I found this which may be relevant for #if OBJC stuff:

http://stackoverflow.com/questions/9225894/mfmessagecomposeviewcontroller-dismiss-keyboard

(look at the very bottom)

 

[Erel]

Do you want to show the composer dialog without showing the keyboard?

I don't see anything relevant in the link you posted.

 

[JackKirk]

Erel,

Do you want to show the composer dialog without showing the keyboard?

Yes - I would rather send the SMS without the user being involved (as I can in B4A) but failing that I don't want the user able to change it before he sends it.

I don't see anything relevant in the link you posted.

Right down the bottom of the post it talks about:

Try close existing keyboard, before presenting modal view controller with MFMessageComposeViewController:

I only know enough to be dangerous but this looked promising.

Regards...

PS: I don't think this is worth another thread, but I have discovered an interesting little quirk in the B4I
KeyboardStateChanged event - it fires when a keyboard appears or disappears in TextView etc (as documented) - it also fires when the MessageComposer dialog disappears (but not when it appears).

 

[Erel]

Try close existing keyboard, before presenting modal view controller with MFMessageComposeViewController:

I don't think that it will do anything useful. You can call Page.ResignFocus to hide the keyboard before you show the composer.

KeyboardStateChanged event is fired whenever the keyboard state is changed (by design).

Which documentation are you referring to?

 

[JackKirk]

Erel,

I don't think that it will do anything useful. You can call Page.ResignFocus to hide the keyboard before you show the composer.

You are right - Page.ResignFocus before and after the MessageComposer.Show statement does not hide the keyboard on the MessageComposer dialog.

Any other thoughts? - I also tried blanking the keyboard out with a panel but can't get it on top of the dialog (I'd also have to know the height which would make KeyboardStateChanged useful if it fired when the MessageComposer dialog launches).

I'll have a play with putting the MessageComposer dialog on a panel and see what happens.

KeyboardStateChanged event is fired whenever the keyboard state is changed (by design).

What I was reporting is that KeyboardStateChanged event fires when MessageComposer dialog ends but not when it launches - a bit inconsistent.

Which documentation are you referring to?

You are right - documentation on the KeyboardStateChanged event is thin on the ground, looking back over my browser favourites I think I relied on:

https://www.b4x.com/android/forum/threads/keyboard-change-language-event.51404/#post-321949

 

[Erel]

Any other thoughts?

You cannot cover the keyboard and I don't think that it is possible to prevent the keyboard from showing.

 

[JackKirk]

Erel,

I am getting increasing irritated by iOS - I'm going to embed a simple checksum in the SMS body and change the parser stack on the receiving end to reject any message that doesn't check out.

Thanks as always for your input...

 

[Erel]

I am getting increasing irritated by iOS

From the user point of view, it is not so bad that apps cannot send SMS messages without intervention.

 

[JackKirk]

Erel,

I wrote my first program when I was 18 - I am now 68 and have been involved in software, developers and users for most of the intervening years in many different roles.

I have never met a user with limited technical competence who needs or copes well with unnecessary complication - such things are always sources of irritation, confusion and frustration - firstly on the user, ultimately on the developer.

The primary design consideration where a user interface is concerned should always be KISS - "keep it simple stupid" (never quite sure how to punctuate it).

One of the characteristics of the smartphone phenomenon is that the vast majority of users have ZERO technical competence - so KISS applies double.

In my view, Apple's nannystate approach to "user security" leads to unnecessary complication - diluting one of their supposed major selling points: ease of use.

Sorry for the sermon...