Closed adad184 closed 11 years ago
It's fine when the keyboard show
2013-04-16 15:27:00.884[2777:907] {{0, 183.5}, {320, 252}}
2013-04-16 15:27:00.899[2777:907] {{0, 176.5}, {320, 252}}
2013-04-16 15:27:00.910[2777:907] {{0, 170}, {320, 252}}
2013-04-16 15:27:00.927[2777:907] {{0, 164}, {320, 252}}
2013-04-16 15:35:08.371[2777:907] {{0, 164}, {320, 252}}
2013-04-16 15:35:08.374[2777:907] {{0, 164}, {320, 252}}
2013-04-16 15:35:08.702[2777:907] {{0, 200}, {320, 216}}
2013-04-16 15:35:08.708[2777:907] {{0, 200}, {320, 216}}
but when i type some word it's going to be wierd , the origin.y became negative
2013-04-16 15:35:09.906[2777:907] {{0, -64}, {320, 216}}
2013-04-16 15:35:09.908[2777:907] {{0, -64}, {320, 216}}
Hey,
What 3rd party input method are you referring to? Could you possibly provide an example project that reproduces the issue?
Without knowing anything else, it would appear that the 3rd party input method is adjusting the inputAccessoryView or the keyboard view itself when the user starts typing.
I'm using QQInput(http://down.myapp.com/msoft/179/1106/90117/qqinput_iphone3.0.zip)
It happened in your project's demo too :)
i patched the code myself for this situation
if ( !tableView.dragging && ( keyboardFrameInView.origin.y < 0.0f))
{
CGRect screenRect = [UIScreen mainScreen].bounds;
keyboardFrameInView.origin.y = screenRect.size.height-keyboardFrameInView.size.height-44-[[UIApplication sharedApplication] statusBarFrame].size.height;
}
It temporarily work for me
Er, so I can't read Chinese so it makes understanding QQ a bit harder, but if I understand:
QQInput is some sort of add-on keyboard for jailbroken/dev devices?
QQInput is a input method instead of the original input method on iOS(of course must be jailbroken if you need to replace the input method )
but I haven't test other 3rdparty input instead, the original input method works fine
Unfortunately I have no way of testing of such a scenario, and in any case what is happening is that QQInput is overriding how the keyboard works, and no offense to the developers of QQInput, but they are doing so incorrectly.
DAKeyboardControl outputs the keyboard's window frames as they are, so if there is a discrepancy when QQInput is being used, then it is as a result of an incorrect implementation. Which isn't something sanctioned or supported by Apple.
Even if I were to know how QQInput works, the frame of the UIWindow is the frame, and QQInput is doing something weird behind the scenes....
yeah, so I patched it myself, I realized that's no solution for it, hope my solution can fix it :)
thank you for your time :)
in
CGRect keyboardFrameInView
may be like this :{{0, -64}, {320, 252}}