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.
Any workaround? (in_background issue)
-
I'm writing a Menu subclass of ui.View to add menus to the Actions menu. The menus auto-populate from the contents of the corresponding sub-directory (I have projects, tools, snippets and documents.) The menus default to running the .py files, with an option to edit (except for snippets which is reversed.)
Because of the
ui.in_background
issue I think ( http://omz-forums.appspot.com/pythonista/post/4613099080384512 ) the run or edited .py file must end up in the UI thread and freezes when something like a console.alert is encountered.Can anyone see a way I can work around this?
-
Why not
self.close()
before running the action? I could be wrong, but pretty sure the ui thread stops once you close it, but your class code can continue.(also... out of curiosity, why are you launching with a notification, as opposed to using execfile)
-
@JonB Thanks... I tried moving the self.close() before running the action but the result is the same. Yes I started with
editor.open_file
and execfile, that's where I first encountered the problem. I tried the silent notification in the hopes it would break the action out of the UI thread. (The simplest case is in the 2 files Test.py and Test2.py posted to the bug thread - Test.py uses editor.open_file) -
I think the problem is that close takes time to execute. wait_modal is what you want to ensure main ui thread is done before proceeding... This works
@ui.in_background def _lsA(self, sender): self._row = sender.tableview.data_source.items[sender.tableview.selected_row[1]]['title'] if self._row != '': if self._bEd: target = self._sD + '/' + self._row+'.py' else: target = self._sD + '/' + self._row +'.py' #notification.schedule('', 0.1, '', 'pythonista://' + target) self.close() self.wait_modal() execfile(target)
-
@JonB Thanks... I tried it with running my Test2.py file. Yes, you can run it one or more times... but if you then open Test2.py using the normal IDE and run it, the IDE freezes. (
editor.open_in
has the problems sooner). It's as if whatever process the IDE uses to launch scripts has itself got into the UI thread.Test2.py (with keyboard interrupt avoided)
import console console.alert('Test2', button1 = 'OK', hide_cancel_button = True)
-
@JonB If I move the
in_background
from a decorator on the whole function, to just around the execfile, it produces an interesting traceback which shows I think that it hasn't moved it from the main UI thread to the main interpreter thread:Traceback (most recent call last): File "/var/mobile/Applications/95A53DE3-06F7-47CE-8F51-C806FE6FDC41/Pythonista.app/pylib/site-packages/ui.py", line 120, in tableview_did_select self.action(self) File "./mi.py", line 47, in _lsA ui.in_background(execfile(os.path.expanduser('~/Documents/' + self._sD + '/' + self._row + '.py'))) File "/private/var/mobile/Applications/95A53DE3-06F7-47CE-8F51-C806FE6FDC41/Documents/tools/Test2.py", line 3, in <module> console.alert('Test2', button1 = 'OK', hide_cancel_button = True) AssertionError: Cannot show alert from main UI thread