* This is now done even before the stdout/err redirect.
* The function is now called no_other_instance_running() to make the
conditional use of it read more naturally.
* For now this *append* logs to the plain log file. **BUT** any
subsequent write by the already-running process will be over the top
of this, so a future commit will use a popup instead.
# Conflicts:
# EDMarketConnector.py
1) Don't log in this check, we're a different process.
2) But we've stomped the plain log file already!
3) Python 3.8.6 seems to not like sys.exit(0) from that ctypes code, so
`return False` instead and check the return from EnumWindows().
And added `# type: ignore` comments.
This is a mess. On the tkinter side it *is* an int, default 0. But
enough python stuff has assumed it's a bool for typeshed to define that
tearoff should be. It doesn't match, mypy complains.
* retry_for_shipyard() was only called by itself (for further retry),
and tried to call self.eddn.export_shipyard() which doesn't even
exist.
I suspect this has been unused code since the EDDN code was extracted
out into an internal plugin.
* self.drag_offset given proper typing.
* All functions have at least some typing now. Left the 'event' Tk
arguments bare as mypy seems to infer without complaint.
* Ignore Tkinter 'name' complaints. I've opened
<https://github.com/python/typeshed/issues/4658> to get this
fixed in typeshed.
* If checking `import update` so it's available.
* Don't annotate journal_event 'event' arg, as it's passed through Tk
events mechanism, so let mypy infer it.
This is the code path for when something ignores the ddeexec registry
key and instead invokes EDMarketConnector.exe with the edmc://...
argument directly.
Our response is to try ShellExecute() to invoke the DDE path instead.
If the DDE path isn't set up (registry key
`Computer\HKEY_CLASSES_ROOT\edmc\shell\open\ddeexec` not present and
correct), then this will cause a loop of repeatedly invoking
EDMarketConnector.exe.
That key is inserted by the installer. The only reasons for it to not
be there would be something blocking the installer from creating it or
something removing it after install.
This way we can tell the difference between:
1. This process obtained the lock.
2. Another process has the lock.
3. We couldn't get the lock due to not being able to open the lock file
read-write.
Case 3 is currently also returned if the configured journal directory
doesn't exist. This will be the case on any MacOS system that never had
the game running. Likely given the OS hasn't been supported for the
game in years now.
I was testing the new Steam or Epic CAPI auth. My EGS account hasn't
yet been used, so has no commander attached. EDMC thinks the auth has
succeeded in this case, but hitting 'Update' causes it to error because
the returned data is empty.
So, add some checks for lack of 'commander' key and a specific message
"CAPI: No commander data returned" for status line.
Without this there's a KeyError exception thrown, causing the status
line to just get 'commander' in it, which isn't helpful.
The actual duplicate process checks *used* to be done in this function,
but no longer are. Instead it's now specifically performing the "is
this an edmc:// auth callback?" check, including the foreground of the
extant process if needs be.
* Implement JournalLock.release_lock().
* Renamed other methods to remove journaldir_ prefix.
* Slightly tweak the code flow for obtaining the lock.
* Implement JournalLock.update_lock(), called from AppWindow.postprefs().
Without this we only truncate to where the file was when we did the
stdout/err redirect.
What I observed was it truncated out the "journal locking" output, but
not anything from a prior run of the program.
