A Dialog Window may not be tightly scoped, and may be around
for a while (query settings from the dialog instance). The destructor
may only be called later.
This can be hard to reproduce and I have not been able to work out the steps to
reproduce reliably, but as it is still occuring work around the issue by just
checking the variable is valid before dereferencing it.
Resolves: #7304
eg. at the end of a loop, the session may already be playing the
beginning of the loop. The TransportLooped signal was emitted.
Yet due to playback latency, the audible frame is still at the end of
the loop.
To interpolate the playhead position the UI needs to be able to know:
Relying on the TransportLooped signal is not sufficient because it
does not take playback latency into account.
Lua serialize() is called recursively and concatenates strings.
(in Lua that results in a new string on the stack, with 2 unused old
strings). Collecting garbage every time becomes expensive, so do it
only once at the end. GUI scripts are not memory limited anyway.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
since 6dc3bdf, a const string reference would leave scope with Lua code
fn("text")
calling a C++
fn (const std::string&)
before the C++ function is called.
