Any workaround? (in_background issue)

[A Former User]

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?

[JonB]

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)

[A Former User]

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

[JonB]

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)

[A Former User]

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

[A Former User]

@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