Forum Archive

I am sure the subject has come up before, but maybe there is a solution now. Is just about presenting a sheet. I am pretty sure, In std Pythonista there is no way to have it appear other than the middle of the screen. Even after its presented, no way to move it. The only reason I ask, this can be very counter productive when you need to interact with the keyboard. In the pic below, the list gets filtered on each keystoke. But the list gets obscured by the keyboard. If I could move the whole view up which is dead space, I could keep a reasonable size window without it being obscured. I know you can use a popover, it's ok, but I want a sheet. I realise the sheet view only works on iPads, but iPads are valid devices 😱😁

the overlay class part of my pythonista backend for matplotlib does this of course.
You could also present a larger transparent "shield" view, with your custom view inside. Then your view can go wherever you want.

@JonB , yeah I understand. Actually I was using your overlay class today. But my point is that it does not make sense for at least some cases that sheet is anchored to the center of the screen. There are always work arounds I guess, but how do you remember them all. And if you share your code how do people understand your work around. Just saying, the work arounds should be worked into the normal workflow at some point if there are reasonable use cases

I've had already this problem and I had set the height of the sheet so the keyboard was just below the sheet, without hiding it. Of course, the sheet became smaller...
In my case, it was sufficient but I agree that doesn't solve your problem.

@cvp , agreed. You have to get crazy small before it starts to work out. Then if you have a toolbar on the bottom of your view that gets updated on what keystrokes you pressed , well you can't basically. I am not trying to be smart. But often people ask why do you want to do what you are doing. But I would say that using a sheet (without a work around) for a view that filters a list is not workable. I also know there are recipes to move a field in a list/Ui.ScrollView response to the keyboard showing. But in this case want the whole view to be visible when the keyboard is shown.

In landscape, the form sheet automatically slides up(but never beyond the status bar)... this is an @omz question, as this seems to be perhaps a custom view controller mode, not a standard modal sheet.... maybe was just oversight.

it is possible, with objc, to slide up the containing view, triggered in keyboard_frame_did_change (pro tip: check onscreen in this method, and also set self.keyboard_frame_did_change=None in will_close so that in keeps running code until you restart!

Kind of annoying, as it requires traversing up the view chain 4 or 5 times, and doing some math to figure out the view geometry.

@JonB , thanks. That's what you get when you stay in one mode all the time. I am always in portrait and only every swivel to check view orientation sizing. In landscape, I can get a view approx 500h without the keyboard obscuring the view, with portrait I can get a view of about 550h without it moving of course. Also, the options added to the keyboard could also affect this a little.
But I think you are right, after seeing how this works in landscape mode, I think this may have been an oversight. Not going to try the tricky things, I will make a issue on Github

@JonB I tried to integrate your "Overlay" class in one of my old "sheet" view script but it crashes Pythonista every time. However, if I show "Family Resemblance" in the same code right before l present my sheet both appear on the screen although the moving capabilities of "Family Resemblance" do not work anymore. I will try it with a simple vintage script like calculator and let you know what happened.

if you are asking for help, a gist or code is helpful. otherwise i can only guess.
If you are experiencing crashing, you should install dgelessus's fault handler to log the exact cause for the crash (the latest beta does this automatically)

@JonB Thank you for the information. I installed @dgelessus routines and they are excellent. The "faultlog" reveals that I was not calling overlay from the main thread which as was not. At least I think that is what the following message indicates:
NSInternalInconsistencyException: Only run on the main thread!
By the way "Calculator" shows as expected. However the buttons were not functional also as expected, and the motion was disabled.

Did you fix your problem? If not, please post a minimal code example which fails for you. I cannot debug a problem I cannot reproduce!