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.
... 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.
Having lots of rules in RuleTable may lead to an assertion failure on opening preferences dialog:
> assert "sz.x <= 1000 && sz.y <= 750" failed in
> PrefsDialog::PrefsDialog(): Preferences dialog exceeds max size
This change will make the RuleTable scrollable (as it is/was when creating many rules) instead of expanding the dialog size.
Further I had to fix the calculation of the clicked row from the given coords. Even without this proposed change for scrolling, the calculated row has always been the one above the clicked row - maybe this changed in wxWidgets 3.0.
Now it uses CalcUnscrolledPosition() which seems to work fine even without scrolling.
Last change is for drag and drop mode: rules are not being copied, but moved on dnd - I changed this to reflect this mode on the cursor while dragging an item.
Thanks to Darrell Walisser for the outline of the problem, which was causing laggy dragging of stereo track sizes in spectrogram view.
This was caused by refreshing the horizontal ruler unnecessarily.
