Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
crash/hang console.input_alert
-
When the input comes up Pythonista hangs. The decorator is in place (I assume correctly). Any help is much appreciated! >> Gist Link <<
-
https://omz-forums.appspot.com/pythonista/post/5019220316258304
Bottom line, use a delay, or
hud_alert
if you don't need input. -
User input is required. I'm not having any luck with a delay. I've bumped it to a whole second and I still get hangs. I took out the animations from the function and still to no avail. Thanks for the tip.
Edit: more info
Let me increase the mystery... As it sits, the input dialogue functions. If you simply trigger it and do not attempt to add text the result is an empty entry in the TableView. If you trigger the keyboard in the input dialogue you will cause a hang.
-
Sorry, I misread.
Input_alert
seems to always hang. Alert works with a proper delay. I have aninput_alert
replacement hanging around somewhere, implemented as ui components.
I'll dust it off tonight and post. -
Ok,see here. this needs a little cleanup and commenting, but it should work. This is a version of input_alert implemented entirely as ui Views.
Basically, add to your gist
from InputAlert import InputAlert
at the top, then
inp=InputAlert() the_view.add_subview(inp)
after you
load_view
. Finally, change yourinput_alert
line withtitle = inp.input_alert('Title')
I tested this with your gist, and it works.
A few notes s out this replacement InputAlert
-
This does not raise KeyboardInterrupt when cancel is pressed.... thread.interrupt_main does not seem to work, and I could not figure out any other way to raise a KeyboardException. I could have raised another exception, but instead it returns None.
-
This needs to be called within a
ui.in_background
ed function, if called from an action. -
If the view is closed, the function will return, rather than continue to block. This might cause strange behavior in some cases, i.e, user may have wanted to cancel, but instead it will be as if they pressed ok. so you may want to check if the view is on screen before taking action. I'll probably update this to return None of not on_screen...
-
-
Thank you JonB! Awesome. I will implement it tonight. "you da real mvp"
-
@jobB Where does the decorator 'enabled.setter' come from? What does it do?
-
Where do you see that? Which file?
that looks it might be an @property. If you declare a variable with a a function name, deformed by @property, several other decorators are created automatically, letting you create object properties with custom get/set methods, but still using regular someobj.someproperty=somevalue type syntax. -
In your uiCheckBox.py class definition
@property def enabled(self): return self._cb.enabled @enabled.setter def enabled(self, enabled): self._cb.enabled = enabled if not enabled: self._cb.bg_color= (0,0,0,0.2) #darken button else: self._cb.bg_color = (0,0,0 ,0)
-
Just got it. When you decorated enabled as a property, you then create its setter and deleter methods. Thx for for Beazley, Python eseential references. Being a dinosaur, I've never been exposed to decorators until pythonista.