DonationCoder.com Software > Clipboard Help+Spell

CHS Feature Request: Switch to "New" folder on certain hot-key actions

<< < (2/3) > >>

mouser:
Since the CTRL-C function works correctly, why not simply have the CTRL-ALT-C function call the CTRL-C function as a subroutine
--- End quote ---

well see, that's the confusing thing -- it's not like Ctrl+Alt+C has its own independent code, it should already be doing exactly that, they should be sharing the same code and it's hard for me to understand why Ctrl+Alt+C could fail and not normal Ctrl+C..  But I should look into code more to see if there is something fishy i'm doing that could explain it.

superticker:
Have you tried searching the entire clip database for the text to see if maybe its just going into the wrong group?
-mouser (September 17, 2012, 03:41 PM)
--- End quote ---
I'll try that next time it fails. That's an interesting idea.
-superticker (September 17, 2012, 04:05 PM)
--- End quote ---
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.

mouser:
One is that the new clip was never captured at all by the CTRL-ALT-C operation.
--- End quote ---

It just occurred to me that this seems to confirm why this is failing, and it has to do with how Ctrl+Alt+C needs to operate.. It needs to send a simulated Ctrl+C keypress to the active window to trigger the capture, after which it shows the CHS window etc.

So in fact this operates very differently from normal Ctrl+C, which windows handles and then INFORMS CHS about via an event after the fact.

It could be that when its sending the simulated Ctrl+C keypress, it's getting tripped up over the alt key still being held down, or over losing focus in the active window -- that's the kind of thing that could happen unpredictably.

Let me go through the code now that I realize that, and look for places where it might mess up.

As a minimum first step, I can have Ctrl+Alt+C process only make the copying sound when it actually succeeds in simulating a ctrl+C copy to the clipboard prior to triggering -- that will at least give us an audible clue when it KNOWS it failed to capture the last clip.  I suspect though that now that i know the problem, I should be able to fix it.

superticker:
One is that the new clip was never captured at all by the CTRL-ALT-C operation.
--- End quote ---
It could be that when its sending the simulated Ctrl+C keypress, it's getting tripped up over the alt key still being held down, or over losing focus in the active window--that's the kind of thing that could happen unpredictably.
-mouser (September 24, 2012, 08:41 AM)
--- End quote ---
Perhaps you could "temporarily" add a timed delay between the simulated CTRL-C and the next operation to see if that fixes it.  If it does, then you've discovered where the race condition is.  Once you know that, you can design a callback completion routine so you don't need the timed delay.

Also, rather than using a callback routine, you could replace the timed delay with a semaphore guard.

mouser:
I'm trying a fix in the new version about to some out, let me know if you notice any improvement.

Navigation

[0] Message Index

[#] Next page

[*] Previous page