Have you tried searching the entire clip database for the text to see if maybe its just going into the wrong group?I'll try that next time it fails. That's an interesting idea.
The problem occurred again, and the new clip isn't present even after searching the entire database. But I did try pasting what was in the current Windows clipboard buffer and, to my surprise, it's not
the new clip. Rather, it's the previous clip in the New folder.
So there are several possibilities here: One is that the new clip was never captured at all by the CTRL-ALT-C operation. Instead, the previous clip was copied from the New folder to the Windows clipboard buffer instead when the captured sound was played.
The other possibility is that the new clip is placed on the Windows clipboard buffer okay, but then immediately overwritten by the last clip in the New folder when the captured sound was played.
Do you have any other questions?
What confuses me is why this failure is non-deterministic so it can't be easily reproduced? It's as if there's some kind of race condition that occasionally is met, but only rarely. Are there two asynchronous Windows events that are colliding with each other 10% of the time? Perhaps you need a semaphore to keep these two asynchronous Windows events from accessing the same shared resource simultaneously.
I see this kind of thing with device drivers because they service many "incoming" (outside) asynchronous requests, but not so much with OS-events within applications.