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

[superticker]

Whenever I add a new clip via CTRL-ALT-C, and the Clipboard Help+Spell window opens, it's not always on the "New" folder as expected. It would be nice if it automatically switched to the "New" folder with this hot-key action.

I'm not so sure, however, if it should switch to the "New" folder with a CTRL-C action alone.  I'll have to think about that.  I think the switching to the "New" folder should only happen when the hot-key action grabs a new clip and presents the CHS window altogether.

There's still a bug present (from a year or so ago) in the CTRL-ALT-C hot key where the clip-capture sound is played, but the new clip isn't actually captured. The work around solution is to use a CTRL-C followed by a CTRL-ALT-C combination to capture clips and bring the CHS window up front. This work around works well.

[mouser]

I know what you mean about wanting it to auto switch to the New folder.. i've gotten bitten by that before.
Let me figure out if it can be done in all cases or if i need an option for some users.

As for the not always capturing -- that sounds like a real bug i haven't seen.. Any more clues about it?

[superticker]

As for the not always capturing--that sounds like a real bug i haven't seen.. Any more clues about it?

-mouser (September 17, 2012, 02:12 PM)

You worked on this bug before about 1.5 years ago, and the fixes you added did improve it. But occasionally, it still fails. What I can tell you is the capture sound always plays even when CTRL-ALT-C fails to capture anything. I'm usually doing this capturing in my email client (Courier) to correct spelling, although other apps are affected as well. I'm running Windows XP SP3 and CHS 2.11.01.

I'm mentioning this bug now because you'll be looking in this area of the code again when adding the switch to "New" folder feature.

Since the sounds always plays and the CHS window always comes to the front (as expected), I'm now wondering if the clip is put on the Windows clipboard buffer okay, but the clip just occasionally fails to show up in the "New" folder for some reason when CTRL-ALT-C is used? I guess I could try a paste operation upon failure and report back to you. Give it a couple weeks to happen again, then I'll report back.

[mouser]

I'd just love any clue if you can find it about when Ctrl+Alt+C fails or a way to reproduce the failure.

Have you tried searching the entire clip database for the text to see if maybe its just going into the wrong group?

[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)

I'll try that next time it fails. That's an interesting idea.

Since the CTRL-C function works correctly, why not simply have the CTRL-ALT-C function call the CTRL-C function as a subroutine, then open the CHS window with "New" folder selected? In other words, simplify the code to fix the hidden problem.

[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

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)

I'll try that next time it fails. That's an interesting idea.

-superticker (September 17, 2012, 04:05 PM)

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.

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.

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)

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.

[superticker]

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

-mouser (October 19, 2012, 10:03 AM)

Yes, I'll check for the race condition. But I may need to run it for a week or two before I can say for sure if it actually went away. With these nondeterministic problems, it's hard to be sure.

[mouser]

Understood.

[superticker]

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

-mouser (October 19, 2012, 10:03 AM)

Yes, I'll check for the race condition. But I may need to run it for a week or two before I can say for sure if it actually went away. With these nondeterministic problems, it's hard to be sure.

-superticker (October 19, 2012, 10:28 AM)

I can now confirm that the new-clip sound is played when the CTRL-ALT-C fails to capture the new clip with version 2.17.1. But it's also worth noting that this now occurs very rarely (under WinXP 32-bit). Something must have changed to reduce the affect of this race condition.