... Unnecessary because transitively included.
But each .cpp file still includes its own .h file near the top to ensure
that it compiles indenendently, even if it is reincluded transitively later.
... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
... for wxString and wxArrayStringEx, holding file paths (absolute or relative,
directory or plain file); to be replaced later with different types
(not yet using std::vector, becase of some uses of wxArrayString::Index with
two arguments)
... Replacing:
Insert => insert
RemoveAt => erase
Remove => erase
IsSameAs => operator == or operator !=
(but only when second argument was true or default)
... which will make it easier to change the types of those containers to
std::vectors of other string-like classes
for wxString,
IsEmpty => empty
Clear => clear
Alloc => reserve
for wxArrayString,
Count => size
GetCount => size
IsEmpty => empty
Add => push_back
Clear => clear
Empty => clear
Sort => std::sort (only with default comparator)
SetCount => resize
Last => back
Item => operator []
Alloc => reserve
... and similar wx "variadics," which all treat wxString smartly enough that
you don't need this.
Don't need c_str either to convert wxString to const wxChar * because
wxString has a conversion operator that does the same.
... There are four different code paths to test, for four different "Download"
buttons:
The two "Download" buttons in the Libraries preference dialog; and,
The Download button in each of the two dialog boxes that follow the two
"Locate..." buttons.
There are just two new help pages in a proper build of local help, each the
target of two buttons.
One of these pages is called "FAQ:Installing the FFmpeg-Import-Export Library"
rather than "FAQ:Installing the FFmpeg-Import/Export Library"
because there are some difficulties preventing links to pages with "/" in the
title, which I didn't try to fix.
Previously this was hard coded to use the online alphamanual.
Some other help-on-errors paths were hardcoded to use the online manual, and did not use local help even if available, so these were changed too.
Also two naming changes in the code:
ShowHelpDialog() became ShowHelp() because it typically shows the help in your browser, only showing the help in a dialog under certain circumstances.
The helpURL parameter became helpPage since it is usually a page name that is then elaborated into a url.
The Link() function became InnerLink().
Some careful http -> https changes made too.
... This includes failure paths in the initialization if import. Those
resources would have been reclaimed before program exit, but not as soon as
they should have been.
... This also includes certain leaks that would happen every time a file is
successfully imported or exported. We never used avformat_free_context or
av_dict_free as we should have!
... There were also AVPacket objects repeatedly reinitialized without proper
cleanups in between. That might have leaked memory too.
I could see this on windows:
Import a file such as .aiff format, while "Files of type:"
reads "FFmpeg-compatible files".
Leave Audacity running.
Attempt to delete the file in Windows Exploerer.
Get a message from Windows that the file is in use by Audacity and cannot be
deleted.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
The value in audacity.cfg is now prepended to the PATH
variable instead of appending it, so that directory
should be searched first.
It doesn't do fallback searches if the first attempt
fails.
But, it made another issue visible...several exporters
fail silently and the user may thing the export was
successful when it was not.
Will be hitting that next.
When the avutil_version and avcodec_version symbols are not found, fall back to
guess the filenames of avutil and avcodec (as done in r13195 and previously).
The non-monolithic libavformat is linked against libavcodec and libavutil.
Instead of (falsely) guessing the filenames of libavcodec and libavutil, get the
files that the libavformat library is linked against. This fixes wrong filename
guesses and avoids run-time issues by using incompatible libavcodec/libavutil
version with libavformat.
