* If there's no replay context we can still use the live connection to
copy and delete captures remotely. Try to use that whenever possible
and warn the user when it's not possible (i.e if the program has been
closed and there's no replay context, we have no way to access the
files anymore).
* If the user tries to open a remote log without a replay context,
prompt them either to swithc to a replay context on that host or to
save the log locally.
* This can happen if the program is closed, and no remote replay context
is active. Unlikely locally, the UI cannot natively save or delete
temporary captures.
* In a couple of places I had to resort to if(IsHighContrast) but mostly
this is just using system brushes consistently or not assuming black
text.
* The default DockPanel theme doesn't work well, so make a minimal high-
contrast theme for it and assign it everywhere.
* The pipeline flow was using fixed colours, use system brushes for the
different elements and switch based on high-contrast to ensure active
and inactive stages are visible (using ActiveCaption looks bad on
normal themes because it's a big block of colour).
* For some reason the flat toolstrip renderer doesn't handle white-on-
black themes, but the system one does. It's a little clunkier but it
shows up correctly without writing tons of custom painting code.
* Range histogram uses a properly contrasting colour for the border.
* Treelist views use a better system colour for selected rows when
inactive and hovered rows (when high contrast).
* Mesh view grids have a system background instead of white
* Various things (pipeline state, mesh viewe) set text colour when
colourising backgrounds of things instead of assuming black.
* In-application API is bumped to 1.1.0 as a new function pointer is
added to the end of the structure.
* This comes with some caveats - capturing a frame is fairly heavy
weight, so capturing a frame might throw off timing-related bugs you
are trying to capture in subsequent frames. If you know your bug is
every other frame though, capturing two can be a quick way to ensure
you get it.
* Previously if a temporary log was saved once, it would be moved there,
so the user could in theory delete it and lose the only copy of the
log.
* Now the temporary log is held until it's closed in the UI, to be able
to be saved again. If the user saves the log though, this will stop
any "unsaved log" prompts in the main UI window, so there is nothing
stopping the user from saving the log, deleting that copy, then
closing and they'll lose the log without prompt.
* Whenever a child process is hooked, that's passed back up to the UI and
a list is shown with all the child processes of the one you are connected
to in the dialog.
* At any point you can double click to create a new dialog latched to that
process.
* If the process you're attached to closes and has one child, similar to if
you only have one capture made the dialog will close itself and open a
new connection to the child process. This is the case for e.g launcher ->
editor
* This behaviour is overridden if you made a capture, as it assumes you
then don't care about the child processes and instead want to open the
capture. You can always do file -> attach later.
* If it has multiple children when the process closes, the dialog stays
open to allow you to peruse the list and maybe open up a connection to
one of the children.
* This means that e.g. decimal separator will always be . and similar
effects, which avoids the need to have culture specific formatting or
special-case handling around CSV export etc.
baldurk