https://stackoverflow.com/questions/44943995/what-is-main-thread-checker-in-xcode-9

You can just disable main thread checker in XCode. There isn't really a problem with what you are doing, it will work fine as is.

Setvaluesonscreen definitely needs to be wrapped. And all of that business in main where you do v[...]

It is complaining about subviews, not present. So search your code for whenever you call subviews, or do v[name], and wrap that in on_main_thread.

Are you sure this is an error, and not just a warning? From what I read, you can disable ThreadChecker.. these warnings are telling you that this is a bad practice... But if you are not adding/removing views, this seems low risk in this case.

@Gadgettyke said:

calling console time out disabled from outside main thread

It would be helpful if you copy/paste the full and exact error message...

your labelN_update methods should have on_main_thread decorators.
Any place you change colors or set text should also be so decorated.

hmm. you could just try/except around the line throwing the failure you are getting, so at least the valid files get restored.

Do you have an Examples/Calculator.py?

you could also define your own wrench action that runs a script in a thread, so that you don't have to decorate.

On windows you have subprocess. Apple does not allow separate processes on iOS. so you are limited to what you can do with threads.

So, anything which updates the ui should be on the ui thread. Callbacks happen automatically, but if you have some knd of timer which updates the ui, you may need to use objc_util.on_main_thread.

if you gist your code we can take a look

pdb lets you enter a debugging state, that lets you walk up the stack frame, interrogating variables, etc.

for instance here i would be interested in you pressin u a few times until you are at line 242 in Synchronator:

  self.download_remote(dbx, entry_path, '-- Not Found Locally')

then typing

print(entry_path)

(press q to exit pdb)

Alternatively, add a print(entry_path) before that line, and then we can see which(if any) files succeed, and which one failed, then figure out which one failed.

if you are saying it works for a while, then craps out, it may be you are violating a dropbox rate api, and need to add some time.sleep's between each file.

https://www.dropboxforum.com/t5/API-Support-Feedback/Error-downloading-files-from-dropbox-API/td-p/259377

Seems path needs to be the full remote Dropbox path. Maybe synchronator needs to know how you have your Dropbox folders set up ..

Looks like she synchronator is trying to download a file that doesn't exist in Dropbox. Why not fire up
import pdb
pdb.pm()

And figure out which file it is trying to download..

Alternatively it might be saying that your destination path doesn't exist - you'd have to look at the code to see specifically what the issue is