The bug was that when the Equalization effect opens in Graphics mode, the sliders are set to zero, and don't do the right thing. This was caused by my incorrect fix for bug #1346.
Fix is to call UpdateGraphic to set the sliders up. Call to UpdateDraw also added, which includes the appropriate calls to Show, rather than have these in PopulateOrExchange.
Several users have stated confusion about the old message,
thinking that it meant 'changes to the imported file', whereas
it actually refers to the 'project'.
Also fix a couple of compiler warnings.
Fix warning about missing field initializers
Don't compile unused static function
Put braces around sub-object initializers
Fix some warnings for unused variables and labels...
Avoid unreachable code warning
The error message is still a bit strange if trying to overwrite
a different project when the current project has been saved,
(why would you do that?), but probably not worth complicating
the message for such a fringe case.
... In particular, narrowing integer conversions are done only in
sampleCount::as_size_t which asserts correctness.
... And the overuse of that type is now corrected. size_t is now used for any
number of samples that fits in memory or a block file. sampleCount is reserved
to describe an offset into an audio file or wave track or clip, or the
difference of two such. sampleCount is signed, but size_t of course is not.
sampleCount is 64 bits wide, but size_t is narrower (in 32 bit executables,
such as we still build).
Hide implicit conversions sampleCount <-> floating point, -> integer
Change sampleCount arguments, variables, return values to size_t...
Make many conversions sampleCount->size_t are explicit and checked...
Convert sampleCount <-> floating or -> long long explicitly ...
Assert that sampleCount doesn't narrow converting to 3d party types
Define sampleCount as a class, not a type alias...
... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
... with run-time assertions.
I examined each place and reasoned that the narrowing was safe, and commented
why so.
Again, there are places where the sampleCount variable will later be changed
to have a different type, and they are not changed here.
... A non-narrowing conversion out to long long is a necessity, but the
conversions to float and double are simply conveniences.
Conversion from floating is explicit, to avoid unintended consequences with
arithmetic operators, when later sampleCount ceases to be an alias for an
integral type.
Some conversions are not made explicit, where I expect to change the type of
the variable later to have mere size_t width.
... Define lots of operators for disambiguation, but they will go away after
all conversions from sampleCount to built-in numerical types are forced
to be explicit.
