Bug 1623 – Using Ctrl+V to Paste one type of track into another causes the Play button to display incorrectly

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 1623 - Using Ctrl+V to Paste one type of track into another causes the Play button to display incorrectly


Summary:	Using Ctrl+V to Paste one type of track into another causes the Play button t...

Status:	RESOLVED QUICKFIXED

Product:	Audacity
Classification:	Unclassified
Component:	User Interface
Version:	2.2.0
Hardware:	Per OS All

Importance:	P3 Repeatable
Assigned To:	Default Assignee for New Bugs

URL:
Keywords:	test_single_OS

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2017-03-30 05:44 UTC by Peter Sampson
Modified:	2018-08-20 11:51 UTC (History)
CC List:	8 users (show)

See Also:	307
Steps To Reproduce:	1) get some audio 2) add a label to create ab label track 3) select in the label track around the label 4) Use Ctrl+C to copy this 5) click in the waveform or drag a selection in it 6) use Ctrl+V to try to paste the label into the audio track 7) you correctly get the error message "Pasting one type of track into another is not allowed". 8) Click "OK" to dismiss the error message 9) BUT now note the the Play button icon is incorrectly still displaying the Ctrl-modified form Play Cut Preview.
Release Note:	GROUP: Playback * '''After dismissing certain modal dialogs, the Play button may continue to display incorrectly as the CTRL-modified "Play Cut Preview" button'''. However the button acts in its normal "Play" mode and will revert to Play after use.
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	petersampsonaudacity: Regression- petersampsonaudacity: Test‑OK‑Win+ petersampsonaudacity: Test‑OK‑Mac+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Peter Sampson 2017-03-30 05:44:54 UTC

Using Ctrl+V to Paste one type of track into another causes the Play button to display incorrectly as the Ctrl-modified Play Cut Preview button (see Steps To Reproduce).

Same behavior in all the 2.0.x seies so not a regression and marked as such.

Behavior does not obtain in 1.2.6 as we had no Ctrl-modified Play button back then.

Comment 1 Peter Sampson 2017-03-30 08:37:04 UTC

Additionally occurs when using CMD+Space on Mac, where this command invokes Spotlight search.

Comment 2 Gale Andrews 2017-03-30 23:39:33 UTC

It does also happen when you drag a selection at step 5, which is more obviously wrong and the only reason that would make me think of P3 here. 

* The first line of a Release Note should start with "GROUP:" but the Group name after that should not end with a colon.

* The next line of a Release Note should start with a "*" so that it will be properly indented on the Wiki Release Notes.

Comment 3 Paul L 2017-07-21 23:11:11 UTC

See old bug 307 and the funny workarounds implemented with it, including a wxTimer.

I now think the right way to handle that and this and remove the code complications is to use wxEventFilter instead.

But, considering the stuff Leland did in CommandManager.cpp for event filtering in wx3, there may be surprises with this approach on macOS.

So I will not attempt to fix this until 2.2.1.

I have updated the Release Note, according to my understanding of this now.  This might happen in more situations than Ctrl+V.

Comment 4 Paul L 2017-07-22 19:10:33 UTC

On second thought... I think it is very safe.  Only need to listen for events, never intercept them

So here it is:

https://github.com/audacity/audacity/commit/d9c3a02542c0457188bc7b8aa6d8baa0e3dc9c45

Comment 5 Peter Sampson 2017-07-23 12:02:48 UTC

(In reply to Paul L from comment #4)
Tested on W10 audacity-win-rf1aa916-2.2.0-alpha-23-jul-17
and on macOS 10.12.5 with Cliff's nightly build of 22Jul17

Works ok with proper play button resored at Step 9 on both platforms.

At step 6 the Play button changes to the Ctrl/Cmd modified Play button.
It remains so in steps 7 & 8 untile you use the OK in step 8 to dismiss the message (but I think this behavior is ok with the proper play button returning at Step 9

Comment 6 Paul L 2017-07-23 16:30:14 UTC

(In reply to Peter Sampson from comment #5)

Right, the correct image comes back at step 9, and I don't know how to do it sooner.

Good enough?

Comment 7 Peter Sampson 2017-07-23 17:29:23 UTC

(In reply to Paul L from comment #6)
Good enough for me - but we need a Linux test before I can close this off