@ExcellentOrg despite the tone both answers are correct. And you may have long ago solved this problem .... especially since so much time has passed. Me, I would probably go with the TCP/IP solution for no better reason than one is essentially a server the other a client and as long as you which starts when that should be easy. Named pipes seem to be very cool and work really well in a 1:1 application. Doug

I am a Traveler of both Time and Space

JSchell, I see your point. Solving a specific type of problem this way can lead to overly complex code on some ocassions. However, this is really a specific problem that I tried to explain in a way that required the fewest words in an effort to avoid confusion. This problem I have solved a couple of different ways and I am faced with it again. I was not completely happy with my other solutions. Having spent the majority of my career working in the Unix/Linux world these things are done differently. While I have written a lot of desktop code in the MS environment I find that I am trying to apply a Unix mindset to Windows desktop problems. I am not sure this is the best way! So the problem remains. Regardless of where the data stream originates (pipe, TCP/IP etc) waiting for a connection and spinning off a thread to handle that communication channel is the easy part. What I find a bit more difficult to find a decent generic solution for. I am beginning to lean toward using an abstract class or an interface to put the burden on the user of the server object. This is just passing the buck so to speak. Unfortunately I also have to use this object! This lead to the original question. What do most folks do when they need to move data from one object to another? I realize that you can just invoke a method in another object if you have a reference but that, in my personal opinion, is wrong. The server object should not know about the consumer of the data he should just make it available. Typically I toss the data into a queue and invoke an exposed event. But perhaps there is a better way? Doug

I am a Traveler of both Time and Space

I am in the process of creating a communications server for an application we are building. Pretty standard architecture, multi-threaded, server waits for connection from remote and starts thread to handle data transfer to and from. Not difficult and lots of examples out here. But what is rarely discussed, maybe because it is application specific, is how data is move from the read callback to the object that needs the data. I prefer to keep the functionality compartmentalized. I have done the queue with a event/delegate implementation. That's fine if all the clients data ends up in one place for processing. But what if an object needs to be paired with a comm handler object? Use an interface? Move the business logic into the handler? That defeats the idea that this should be generic enough to be used in other projects. All thoughts and suggestions are welcomed! Thanks, Doug

I am a Traveler of both Time and Space

Does anyone know if there is a .NET 4.0 help file(s) that I can pull into VS2012? All that seems to be there is .NET 4.5. Thanks, Doug

I am a Traveler of both Time and Space

Richard, thank you. Very much! An excellent suggestion! However after a sleepless night (anybody know why stuff like this always happens on site during acceptance testing?) a good friend this morning showed me error of my ways. You, see, the only problem was I have a wretched case of idiotitis. In my zeal to explore the nooks and crannies of this Windows world I made the decision that a nice clean way to allow objects to get information from other objects was exposé an event and delegate. Seemed reasonable to me at the time. Having spent most of my life in a world where objects on different threads have REAL boundaries I assumed that if some object from another thread registered a handler that naturally when that handler was invoked from thread 2 that the event would interrupt thread 1 it would process the event and thread 2 would go merrily on its way. Nope. Thread 2 runs the event handler. Well when the thread that is minding your comms is now suddenly executing code in MainWindow which consists of putting up a dialog guess who isn't watching his comms. Error of my ways #2 has to do with where one starts threads, which is the point you are making. I was informed that launching critical long running tasks from the MainWindow code was not a very good idea. Suggestion was to move them to the App class and override OnStartup. Which I have now done. That does create several questions but I will save them for another day. Error of my ways #3 was to foolishly mentally assign characteristics to objects in threads as I would to a process of lightweight thread in other operating systems. Not a good analogy. Sorry for the length but somebody out there will make the same boo-boo someday. Thank you again, Doug

I am a Traveler of both Time and Space

Ladies and Gentlemen, i have had something rear its ugly head today and I frankly do NOT for the life of me understand how this can be. After spending a couple of hours PROVING to myself (I am not always easily convinced) that what I am see is real, I scoured the net to the best of my googling abilities and came up empty. So I lay this at your feet hoping someone here has an answer. Naturally, I am on the customer site with a hard deadline and more than just my reputation at stake! I will spot you that I am NOT the most experienced Windows developer on this plant, but I have been around the block a few times. Here is my story. I have created a WPF application that is very much multi-threaded. In fact it is highly dependent on these threads. There are 5 main threads: 1) UI; 2) TCP/IP server; 3) GPIB client; 4) main application; and 5) the main application interface. When the app starts, MainWindow runs as with most WPF type apps. In the constructor I create some little class to do this and that and I instantiated each of the objects for the 4 main threads (obviously I am in the UI thread). Once the constructor is done the app drops into the normal sort of WPF wait for something to happen kind of thing. Meanwhile my other threads are busy handling comms, reading files and a variety of other things. When a particular msg arrives via TCP/IP the MainWindow is notified and he throws up a Window being used as a dialog. nothing fancy, just var dlg = new myWindow(); dlg.ShowDialog(); Here is where it gets REALLY weird! Every thread in the app stops! Freezes. Goes out to lunch! Describe how you wish. But they freeze. When the dialog is dismissed everybody goes about their business like nothing happened. Of course the reeks havoc on comm threads. Anybody and ANY ideas why this is happening?? And more to the point what the remedy is? Oh, I create my background threads using: Task.Factory.StartNew(() => { _pxiHandler.MainLoop(); }, TaskCreationOptions.LongRunning); TIA, Doug

I am a Traveler of both Time and Space

Good solution! I am using that in a couple of places and that helps. More I am trying to avoid a mix of EventWaitHandles and delegate/event handlers. I think this is a bit "messy" looking. But with schedule tight sometimes you just have to do what you have to do ;-) Doug

I am a Traveler of both Time and Space

Good tip! Thanks i will look into this. I am using VS2010 so will need the add on. Doug

I am a Traveler of both Time and Space

Sorry for the cross post but this doesn't fit neatly into Silverlight/WPF! I am asking this in the WPF forum because this is a WPF app but this question does not necessarily pertain to WPF, i.e. the UI thread. Here is the scenario: I have three (3) threads. Thread One (1) call it the Master Thread; Thread Two (2) is a Ethernet Comm thread; and Thread Three (3) is a GPIB comm thread. Both communication threads handle asynchronous communications from remote entities. At this time there is only one entity hanging off each comm type. I have implemented a mix of EventWaitHandles and delegates. This all works pretty well. Just think this architecture is a bit ...... ugly. So which one is better/safer? My concern is as follows. With delegates, for example, the Master thread registers an event handler with Thread 2 and an event handler with Thread 3 for messages that come in. Obviously data could come in near simultaneously. So Thread 2 encases a message in an EventArg and invokes the event on the Master thread. The Master Thread begins processing and then Thread 3 encases its message in an EventArg and invokes the event on the Master Thread. What happens? Does the Master Thread stop in the middle of handling the first event to service the second one? Does the second event wait until the first event is processed? What if Thread 2 gets another message and invokes the event again while the Master is processing the first event? I wonder if using a queue and an manual Reset EventWaitHandle is not a better idea as the Thread 2 can check the status and wait until it is reset before putting the message in the queue and setting the EventWaitHandle again. Opinions, please? Thanks, Doug

I am a Traveler of both Time and Space

I am asking this in the WPF forum because this is a WPF app but this question does not necessarily pertain to WPF, i.e. the UI thread. Here is the scenario: I have three (3) threads. Thread One (1) call it the Master Thread; Thread Two (2) is a Ethernet Comm thread; and Thread Three (3) is a GPIB comm thread. Both communication threads handle asynchronous communications from remote entities. At this time there is only one entity hanging off each comm type. I have implemented a mix of EventWaitHandles and delegates. This all works pretty well. Just think this architecture is a bit ...... ugly. So which one is better/safer? My concern is as follows. With delegates, for example, the Master thread registers an event handler with Thread 2 and an event handler with Thread 3 for messages that come in. Obviously data could come in near simultaneously. So Thread 2 encases a message in an EventArg and invokes the event on the Master thread. The Master Thread begins processing and then Thread 3 encases its message in an EventArg and invokes the event on the Master Thread. What happens? Does the Master Thread stop in the middle of handling the first event to service the second one? Does the second event wait until the first event is processed? What if Thread 2 gets another message and invokes the event again while the Master is processing the first event? I wonder if using a queue and an manual Reset EventWaitHandle is not a better idea as the Thread 2 can check the status and wait until it is reset before putting the message in the queue and setting the EventWaitHandle again. Opinions, please? Thanks, Doug

I am a Traveler of both Time and Space

Maybe data flow isn't the right question, maybe application organization describes my quandary a little better. Here is what I am trying to do and could stand a bit of help getting there. The app I am creating basically sits between two pieces of equipment and provides data management and communications management between the two. On one side is a piece of equipment that views its world as dealing with a single entity that provides a go no-go result. The other side is a piece of gear that can have of measurements to keep up with. Essentially all this data must be gathered, analyzed and a go no-go be sent. One side expects a TCP/IP server the other is a GPIB bus master. The comms are handled as that was the easy part. Where I am a bit stuck is gluing all this together. The GPIB code and the logic to handle the data is done and runs as a task. The TCP/IP server is done and it runs as a task. I need to add one more piece of logic to handle the decision making plus have a UI that needs to be kept up to date. Right now I have test programs for testing the comms etc. There I have the UI registering event handlers to get notifications of something happening. I use EventWaitHandles to notify the thin interface layers that sit about the comms. All works great! But when I put all this together..............??? I want areas of functionality as loosely coupled as I can for better reuse. In the UNIX world this is simple but in this world, not so much. My inclination is let the MainWindow code behind kick off each task and the tasks expose public methods or permit registering event handlers. But something about this doesn't feel right. In the UNIX world I would have started POSIX threads to handle each functional area and used message queues to facilitate data flow. That way synchronous functionality is grouped and asynchronous is grouped. But the Windows world doesn't seem to operate that way. What I have seen is all the classes/objects are gathered into a single app and there is a lots of "peeking" over the wall to do things which I think tends to make things very tightly coupled. Suggestions? TIA, Doug