Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / February 2008

Tip: Looking for answers? Try searching our database.

Windows Service & Clipboard

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Humam - 25 Feb 2008 13:38 GMT
I am developing a windows service that read data from a device attached to a
PC via serial port, then service should put the data in the clipboard.
I am writing this code:

Clipboard.Clear();
Clipboard.SetText("Some Text");

but for some reason, no data is sent to the clipboard!
Is it because Windows Service run on a seperate thread?
Can any one help?
Jon Skeet [C# MVP] - 25 Feb 2008 13:55 GMT
> I am developing a windows service that read data from a device attached to a
> PC via serial port, then service should put the data in the clipboard.
[quoted text clipped - 6 lines]
> Is it because Windows Service run on a seperate thread?
> Can any one help?

Have you allowed the service to interact with the desktop? I believe
the clipboard is inherently tied to the desktop, and services aren't
normally meant to interact with the UI at all.

(I have to say, it does seem a very odd thing to do.)

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet   Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Humam - 25 Feb 2008 14:33 GMT
I tried that, but I am still having the same odd result.

> > I am developing a windows service that read data from a device attached to a
> > PC via serial port, then service should put the data in the clipboard.
[quoted text clipped - 12 lines]
>
> (I have to say, it does seem a very odd thing to do.)
Willy Denoyette [MVP] - 25 Feb 2008 18:08 GMT
Only STA threads can access the clipboard, Windows Services threads enter
the MTA by default. Even if you run your clipboard stuff on a new thread
initialized to enter an STA, you will encounter following issues:
1) STA threads must create a Window and pump it's message queue.
2) The clipboard is a shared memory section, mapped in all the processes
memory space running in the same WindowsStation\Desktop pair sharing the
same Session. Windows Services and Interactive applications run in distinct
pairs (unless you set "Access Interactive Desktop", which is a bad idea),
so, by default, they don't share the clipboard.
On Vista ( and on systems where FUS is enabled/used)  it's no longer
possible to use the clipboard to pass data across the session boundaries.
Services and user applications do no longer share the same session on Vista.

Willy.

>I tried that, but I am still having the same odd result.
>
[quoted text clipped - 15 lines]
>>
>> (I have to say, it does seem a very odd thing to do.)
Mr. Arnold - 25 Feb 2008 13:56 GMT
>I am developing a windows service that read data from a device attached to
>a
[quoted text clipped - 7 lines]
> Is it because Windows Service run on a seperate thread?
> Can any one help?

I would think because it's not a Windows Desktop solution, forms based, that
you might have a problem doing that.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.