Greenshot updated from 1.2 branch at commit
e9ab99c5acc99785cc5045b4b5493c9b6504d016
This solves #1341 and #1079 for allowing support high DPI monitors.
Additionally, the following were implemented:
- #748 - Objects can be saved to file and loaded from file via menu
- #676 - Keyboard shortcuts added for 'Save and close' (Alt+S), 'Close'
(Alt+W), and 'Close and cancel tasks' (Alt+C)
- #1189 - Editor opens sized to image. Can be disabled via Greenshot ini
with `MatchSizeToCapture=False`
Reworked single instance code to better handle being launched with
context menu.
Previously:
- On launch, process would try to open an `EventWaitHandle`. If it
didn't exist, then process assumed it was first and created it
- Multiple processes launching at same time would all see the
`EventWaitHandle` did not exist before any process could create it
- This led to multiple instances of program running
Now a mutex is used:
- Processes will all try to open the mutex. Only first one will succeed
- Process that opens the mutex will setup the `EventWaitHandle`
- Other processes won't get the mutex and will be directed to use the
`EventWaitHandle` to pass their command line args to the running
instance
Current process is as follows:
1. Invoked .exe gets the semaphore
2. Invoked .exe sets `InstanceProxy` values in running exe
3. Invoked .exe causes thread to spawn in running exe
4. New thread in running .exe reads values from `InstanceProxy`
4. Invoked .exe release the semaphore
The problem is that there is no guarantee on how fast new threads in
running .exe will spawn and read values from `InstanceProxy`. This PR
addresses that by moving the semaphore release from the invoked .exe to
the thread spawned in running .exe.
The problem is that multiple context menu selections spawn multiple .exe
(invoked). Each invoked .exe sets the InstanceProxy variables in the
running .exe and tells it to start a thread to process. But, there is no
waiting, so the InstanceProxy variables get clobbered before they can
get used.
This fix uses a semaphore to control the invoked .exe. There is only one
entry allowed forcing invoked .exe to wait until any other invoked .exe
is finished running and releases the semaphore.
