Windows 7 - Clipboard viewer locks on reboot

Asked By Alexander on 06-Dec-08 03:19 PM
I have succesfully implemented a clipboard viewer. I have followed the
documentation to the letter as well as checked the code against
samples in the CP and the source code for Synergy. The viewer works
flawlessly.

The problem comes on boot. The clipboard viewer is set to
auromatically start with Windows (it lives in the System Tray).
However, after booting, it fails to work. Moreover, it locks the
clipboard itself and makes it useless until my clipboard viewer is
closed.

Any thoughts? I've looked over the code a thousand times and rebooted
the machine more times that I can count. I'm truly going nuts over
this.




Alec S. replied on 05-Dec-08 07:12 PM
I’m confused; how does it work flawlessly if it locks the clipboard? How do you
get it to work then? Does it work if you quit it then run it again? If so, then
you may want to examine what that first instance did that allowed the second one
to run. For example, is it causing a service to start that isn’t otherwise
running after a boot?


--
Alec S.
news/alec->synetech/cjb/net
Alexander replied on 06-Dec-08 03:19 PM
w do you
, then
ond one
ise

I said it works flawlessly until reboot. Then and only then, it locks
the clipboard. And yes, a restart of the program (after a reboot)
solves the problem.

Some condition I cannot detect is causing my clipboard viewer to fail
on reboot. It only makes sense to think that the problem happens in
the call to SetClipboardViewer (which in turn triggers the message
WM_DRAWCLIPBOARD). But it is all handled as follows:

void CMyDlg::OnDrawClipboard()
{
CDialog::OnDrawClipboard();

// If there is a next clipboard viewer, pass the message on to it
if ( m_hNextClipboardViewer !=3D NULL )
{
::SendMessage( m_hNextClipboardViewer, WM_DRAWCLIPBOARD, 0, 0 );
}

if ( m_bInspectClipboardViewer )
{
...
}
}

I'm calling SetClipboardViewer in the OnInitDialog handler. Could that
be the problem...
Alexander replied on 06-Dec-08 03:19 PM
Narrowing the problem. The locking issue was not an issue after all.
But the clipboard remains inaccessible.

The issue can be replicated by having a second clipboard viewer run
after mine is running. In other words, it seems to be a clipboard
chain problem. The crazy thing now is that all one needs to do to be
added to the clipboard chain is to call


m_hNextClipboardViewer = SetClipboardViewer();


which my app does in the OnInitDialog handler. No messages are sent
when a second viewer becomes active later on. The only other message
is on _removal_ and that one I handle as follows:


void CMyDlg::OnChangeCbChain(HWND hWndRemove, HWND hWndAfter)
{
CDialog::OnChangeCbChain(hWndRemove, hWndAfter);

if ( m_hNextClipboardViewer == hWndRemove )
{
m_hNextClipboardViewer = hWndAfter;
}
else if ( m_hNextClipboardViewer != NULL )
{
// If there is a next clipboard viewer, pass the message on to it
::SendMessage( m_hNextClipboardViewer, WM_CHANGECBCHAIN, (WPARAM)
hWndRemove, (LPARAM)hWndAfter );
}
}

That is, standard stuff. Of course, the problem occurs before
OnChangeCbChain is called since the problem occurs when the second
viewer starts, not when it is removed.

So, summing up. When a second viewer starts, my viewer fails to work
(OpenClipboard works ok, GetClipboardData returns NULL, that is, no
access to clipboard data). Before and after the second viewer is run,
everything is fine. While a second viewer is running, the clipboard
becomes inaccessible.
David Ching replied on 05-Dec-08 10:56 PM
How is your app started with Windows?  In the Windows\currentversion\run
registry key?  In the startup folder?  As a service?  Perhaps the user's
desktop is not active (your app is started too soon)?

-- David
Alexander replied on 06-Dec-08 03:19 PM
Thank you, guys.

The problem was caused by a previous call to EmptyClipboard which
triggers a call to OnDrawClipboard. This was not handled properly and
it lead to the problems I had.

There went a few hours of work...