when using some 3rdparty input method , the origin.y will be negative about dakeyboardcontrol HOT 7 CLOSED

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}}

from dakeyboardcontrol.

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.

from dakeyboardcontrol.

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

from dakeyboardcontrol.

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?

from dakeyboardcontrol.

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

from dakeyboardcontrol.

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....

from dakeyboardcontrol.

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 :)

from dakeyboardcontrol.