LiveCode Forums.

Hello,

I have an app that is 99.99% ready for release on the app markets, and going through final testing, I have found that when I activate the keyboard, the entire stack shifts up to where the bottom of the stack aligns with the top of the keyboard.

This issue is brand new, and I have not changed anything related to it in quite some time. Before this point, the screen behaved very well when a keyboard is activated.

Our app has two stacks included in it, and one of them does not do this, but the other does. It consistently just shifts the entire stack up on top of the keyboard. How is this possible? I assume I must have tweaked something that causes the engine to display this behavior, but I made no intentional change to do so.

Anyone have any idea why this might happen or how I can work around it?

Thanks,
Phil E.

Hi Phil,
Did you set the acceleratedRendering to true?
That will do it on Android.

Simon

Simon,

I had been! OK, now I have that line commented out, and it is working!

Strange that the acceleratedRendering messes that up. Sounds broken.

Anyway, thanks! I'm good to go now!

Kind regards,
Phil E.

Hi Phil,
There is a question on this.
It's good because one doesn't have to do all the calculation to move fields or change the layout out from under the keyboard.
It's bad because it's not the same behavior as iOS.
It would be cool if iOS acted the same.

Simon

Simon,

I see what you mean. I agree that the behavior ought to be the same between platforms, certainly.

I have been playing with the KeyboardActivated and KeyboardDeactivated messages to adjust the screen based on the effective working screenRect, and I feel that the screenRect could be simplified to interact with engine scaling (specifically referring to Resolution Independence) better. As it is now, I have to manually calculate screen ratios, which leads to confusion, though it is possible that for applications other than setting fields in the right place (and out from behind keyboards), there are other uses that I'm blind to at present which make it better as is.

I did ultimately get my calculations figured out, it just meant I needed to differentiate between the height that can be derived from the screenRect and the "height of this stack".

If that were simpler, I could imagine the acceleratedRendering not *necessarily* needing to adjust screens on keyboardActivated as it does, since developers would have an easier time manually changing things.

It's also more than likely that there is stuff going on and interactions that exist that make my thoughts irrelevant!


As always, thanks for the dialogue and the help!
Phil E.

Hey Phil,
Watch out with the KeyboardActivated and KeyboardDeactivated.
On a soft keyboard down KeyboardDeactivated is not triggered.
I note that my Galaxy does not have a "soft keyboard down" (or I haven't found it yet) but it's a key or key combo that allows one to send the keyboard down. I have it on my HTC and Kindle.

Simon

Simon,

Oh boy... any recommendations for initiating the behavior I expect in KeyboardDown when such an action happens? (Would seem there's no SoftKeyboardDown message).

Phil

Hi Phil,
I haven't tested the problem in about a year so best do that first, they may have found a solution for it.

Right now I make all cards that have fields that could be covered by the keyboard a native scrolling group. I have been doing a bunch of testing on other apps and it seems many do it this way.

Simon