The save capture modal message box could process messages which could delete a LiveCapture, the pointer had already been copied into a local list, then try to use deleted memory.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* The 'no to all' option should always be present if there are multiple unsaved
captures across the connections, even if the current connection only has one
capture and so otherwise wouldn't have a 'no to all' option.
* The 'no to all' option will always discard all unsaved captures in all
connections when closing the window, if the user clicks no on the confirmation
of this, abort the close operation entirely and let them decide how to handle
it (e.g. discarding/saving captures in connections individually).
* This means if you're closing multiple connections and click 'no to all' when
prompting save of instead of discarding just the captures in that connection
then going on to prompt for the next, it discards all remaining captures.
* If we save the current capture from a connection window we want to do that via
the main window so the UI can be properly updated and so we can save it
properly through the replay manager, so the old one can be removed safely.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* This option (in spite of large warnings) continues to be a pitfall for new and
experienced users alike, trying to use process injection without good reason
and getting into trouble when it breaks.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* One automodule in a file for our modules is way too much, so we split it into
files. Unfortunately this means that only one file can have those classes and
functions be linkable from elsewhere.
* Instead we bite the bullet and manually curate the items into pages, and at
the same time subdivide the 'enums and data' page more which is a general
readability and usability win as well.
* We also add some previously not-included functions, and add a doc-build time
check to ensure that functions and classes aren't omitted from the
documentation in future
* If no capture is loaded after launching a program, the capture settings can
still be present and cause problems with future launches of applications
depending on the Android version.
* QNetworkAccessManager is supposed to be asynchronous and threaded internally,
but calling get() the first time can take multiple *seconds* while it
initialises proxy data and loads ssl libraries.
* Qt's threading rules are so strict it's impossible to feasibly move
QNetworkAccessManager to another thread.
* Instead we use Qt's cross-thread signals and slots to move the whole thing
into a wrapper object. It's stupid.
* Newer Qt versions will base64 the byte arrays even if we've already base64'd
them so they're safe. To prevent this we explicitly convert to QString
afterwards.
* If the UI was launched with a filename as a parameter to open the capture, it
will be added to the recent capture file list. Only later (relatively
speaking) if we make a capture connection will we realise that it is temporary
and potentially delete the file. If we do so, remove the capture from the
recent file list.
* In particular make it clear that crashes caught in the injected program may or
may not be a RenderDoc bug. Even if we could point the finger to a particular
DLL we can't necessarily tie that DLL to the responsibility of either us or
the application.
* The defaults can be configured from the settings menu, and there's a new "Open
Capture with Options" menu option to open a capture with different options
temporarily.
* This allows RemoteHost handles to still be valid and usable (if returning
empty data) when they are deleted/removed if the device is disconnected, as
well as providing better multi-thread access (they lock internally)
Jake Turner