Skip to content

Conversation

@spy16
Copy link

@spy16 spy16 commented Jul 14, 2018

  • added a Monitor() function which watches the clipboard for changes using ReadAll() function
  • when a change is detected, it is sent over a channel
  • added a demo clipboard watcher utility which simply logs changes in clipboard
Monitor(interval time.Duration, stopCh <-chan struct{}, changes chan<- string) error

@hebestreit
Copy link

Hi @shivylp,

first thanks for implementing this feature!

I'm using your fork in my current project and have some issues on Windows when copying an file before starting the application. I'll always get an error from getClipboardData.Call(cfUnicodetext) in clipboard_windows.go.

I think this is not a problem of your pull request but initially you're setting the currentValue and return if an error occurs. Sadly I can't get this return value when using Goroutines. Or am i wrong?

https://github.com/atotto/clipboard/pull/31/files#diff-f523429d86f9f4660c4360d3d046cee7R27

I'm calling your monitor method in my project at this line and have no access to an error.
https://github.com/hebestreit/clipboard-yt-dl/blob/master/cmd/clipboard-yt-dl/main.go#L80

To solve this problem I've made this changes.

func Monitor(interval time.Duration, stopCh <-chan struct{}, changes chan<- string) error {
	defer close(changes)

	var currentValue string
	
	for {
		select {
		case <-stopCh:
			return nil
		default:
			newValue, _ := ReadAll()
			if newValue != currentValue {
				currentValue = newValue
				changes <- currentValue
			}
		}
		time.Sleep(interval)
	}
}

@spy16
Copy link
Author

spy16 commented Aug 12, 2018

You can probably do:

go func(){
   if err := Monitor(....); err != nil {
       // some way to handle this error
   } 
}()

If that doesn't work for you, the logic of the Monitor is so simple that you can simply copy and build a usage specific version for your particular usecase.

The first error check was there to ensure this function does not set off an infinite for-loop that doesn't do anything. If the first time ReadAll() fails, we don't know the current value in the clipboard and hence, the currentValue != newValue will simply be false all the time and nothing would be sent over the changes channel.

@hebestreit
Copy link

hebestreit commented Aug 12, 2018

I'm of your opinion if the error is not produced by a value in the clipboard like init clipboard.

But in my case I want to have that infinite for-loop because at first there is an invalid value for example a copied file but then I copy another value which would replace it successfully.

Just this error or other errors will be ignored inside of the infinite for-loop. So maybe it is possible to distinguish these error types?

For now I've copied your logic of the Monitor and customized it.

@tehsphinx tehsphinx mentioned this pull request Oct 28, 2018
@tehsphinx
Copy link

Did not see this implementation and reimplemeted it.

Now that I'm done I'm gonna make a PR anyway: #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants