What about polling in a different thread and adding a custom event when data are available? With the current multi-core computers, that should help to remove load from the main (UI) thread of the application. Beware of Control.Invoke/BeginInvoke when you then update the UI on data received from the device.

Yeah, I look at the OutputDataReceived event, and for a moment considered doing reverse text encoding on the string - but that was an absolute last resort :D The threading is handled internally, and has no contact to the GUI. You can se a sample of it at: http://bendtsen.net/sample.txt[^]

Bass (and Bass.NET) rocks hugely! And Bernd (the author of Bass.NET) is very responsive and extremely helpful. I can't praise these toolkits enough. :cool: :cool: :cool: /ravi My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

Thank you - I looked at the list. The problem with many of them is that it is not possible/hard to filter out other traffic. It is very confusing to debug in 500 packages, when 98% of them are irrelevant. I found "Ultra Network Sniffer"; it is perfect for the job. You can monitor any running application. And only packages transmitted to/from are shown. Unfortunately it crashes on Windows Vista :/ - had to move the project to an XP box.

Hi Pete Thank you for the speedy reply! Is it really that simple? - I looked at message security configurations, that seemed far more complex. E.g http://msdn2.microsoft.com/en-us/library/ms789011.aspx Do you know how to specify the credentials on the client side, if entered manually?