the "origin" i'm talking about is the origin of the frame after it is translated to the main view (or atleast a couple views up) with the "convertRect:toView:" code. (to see problem in action with pop up and, must have keyboard effecting popup, move the whole view up then log the "origin" and "size" of popUp after the "convertRect:toView:" code). The tricky part is finding the PopUp bottom, because there appears to be code in the popup itself or the convertRect:toView: code that makes the origin flaky, (if you try to "view" origin after a "convertRect:toView:" code), it wants to move and be in different spots during rotation,(or one of it's super views) so bottom calc comes out different some times,(not predicable) because of async process of the rotation of different elements possibly because the popUp itself has many superviews down in the pop up. took me hours to figure out an absolute always work topOfKeyboard, so here you go.- //. -finding the keyboard top (also used on "didRotate")-very handy, In otherwords, sometimes your UIView will not move at all, sometimes it will move up by a good 170 points. easy to do, EXCept for when you rotate the screen, then things get tricky. This code below is for when the keyboard rotated, similar code for when it is first introduced. you can't just move it up by the size of your keyboard, because popUps up high would then also be effected. The best way to handle this is to temporarily move your entire main UIView of the whole screen up with the keyBoard by the difference between the size of your pop up, and how much that pop up would shrink if you did not move it up. You can not keep the popUp from squishing, UNLESS you move a view. It would be great if it did actually animate to better part of the screen, I think you mean it actually shrinks the popUp which is mostly not good.(which i see during rotation in my case).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |