 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / November 2007Needing info on passing data between applications. Win[C#]
Perhaps someone can point me in the right direction in finding code, or finding reading information on how to pass information (ie. ArrayList, string, etc) between two running window applications, that won't neccessarily be on the same machine. This will be my first attempt at this, and I'm not sure if this falls under COM, or ActiveX. Any and all help is appreciated. Thanks in advance. Mike Mike, Are they both .NET applications? If so, you should be looking into Windows Communication Foundation, or remoting (I urge you to look at WCF though first).  Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Perhaps someone can point me in the right direction in finding code, or > finding reading information on how to pass information (ie. ArrayList, [quoted text clipped - 9 lines] > > Mike Hi Nicholas, Yes they are both Windows/forms .NET C# applications. What I really want to try to accomplish is to send information from one application to another application, where it will (eventually) be sent off to be printed one of various printers. Having the info be send to the 2nd application is to safe-guard, incase the printer name changes, etc. If this works, it might just end up on a server, or on another machine. In my head I'm thinking this is the best course of action, unless there is a better solution out there. But thank you Nicholas, I"ll head off right now and check out WCFand or remoting. Thanks again. MIkeY > Mike, > [quoted text clipped - 15 lines] >> >> Mike Unfortunitly I'm work with VS.NET 2002 and it is my understanding that WCF needs 2005 and greater. > Hi Nicholas, > [quoted text clipped - 34 lines] >>> >>> Mike > Unfortunitly I'm work with VS.NET 2002 and it is my understanding that WCF > needs 2005 and greater. You might consider upgrading. But if not, as Nicholas said, .NET Remoting is also an option if you can't use WCF. Pete Mike, Just curiuous, if the second app is to safeguard in case the printer name changes, then why not just list the printer with Active Directory? If you do that, it doesn't matter where the printer is, as you could give it a consistent name to be accessed by (I believe). Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Hi Nicholas, > [quoted text clipped - 34 lines] >>> >>> Mike > Yes they are both Windows/forms .NET C# applications. What I really want > to try to accomplish is to send information from one application to > another application, where it will (eventually) be sent off to be printed > one of various printers. Having the info be send to the 2nd application > is to safe-guard, incase the printer name changes, etc. without knowing much detail, can't you just abstract the printer(s) so that you print to "Laser" or "Plotter" and let a print provider class handle the details of routing it to the proper device? Alternatively, how about dumping your print files to a directory queue which picks up and routes the jobs? Hi Mike, there is something that may be not that well known in developers heaven, but i think it is the "fastest" method in sending data between two applications running on the same machine. Much faster than sockets, Remoting or any other IPC Method: It is called the WM_COPYDATA Window Message. You can send any size of Data to the target application, and it is fast as ligthning! See here if this could be a option for you: [WM_COPYDATA] http://msdn2.microsoft.com/en-us/library/ms649011.aspx This might be the fastest Solution for two applications running on same machine! Regards Kerem Signature----------------------- Beste Grüsse / Best regards / Votre bien devoue Kerem Gümrükcü Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied." This will work until the program is moved to another machine (which the OP specified in his original post). Also, the it should be noted that in order to do this, you would have to serialize the data into a byte array yourself before sending the data with the windows message. It also fails for service and console applications, it would only be good for two windows applications on the same machine. Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Hi Mike, > [quoted text clipped - 14 lines] > > Kerem Thank you Both, Nicholas & Kerem. Sorry for getting back late. I had to call it a night. But I will use "Remoting" & I'll look into what you were talking about with the Active Directory. Yes, I think we are definitely on the same page with what you were referring to with the Active Directory. LOL I only wish I could upgrade .NET, it would make my life easier on a lot of fronts, but alas, the mighty $$$ gets in the way, or for at least right now. Thanks again MikeY > This will work until the program is moved to another machine (which the > OP specified in his original post). [quoted text clipped - 24 lines] >> >> Kerem > [...] > LOL I only wish I could upgrade .NET, it would make my life easier on a lot > of fronts, but alas, the mighty $$$ gets in the way, or for at least right > now. Why? The Express version is free. The actual framework itself is free. With such an old version of Visual Studio, it's likely that whatever sacrifices (if any...the Express version is actually remarkably full-featured) you have to make are far outweighed by having access to the new C#/.NET features. You should at least give it a try. Pete Hi Nicholas, > This will work until the program is moved to another machine (which the > OP specified in his original post). As i said, a "possible" solution for him if he wants, it "could" be a option for him. The Window Message implies local usage due to the fact that you cannot send window messages to another system the "standard" way without some sort of commuincation protocol like TCP/IP TCP or UDP or something like that. This should be clear here. I dont want to go too deep in IPC, you know what i mean,... > Also, the it should be noted that in order to do this, you would have > to serialize the data into a byte array yourself before sending the data > with the windows message. This shouldnt be a Problem, serializing some data to a byte array. In native Windows you also have to cast something to VOID* or point to some address and tell the function how long your data is, so this is not that different compared to casting something using C or C++ or unmannaged .NET or whatever allows you casting like dynamic, static or whatever casting,... . > It also fails for service and console applications, it would only be >good for two windows applications on the same machine. As i said, since it is a WM_COPYDATA it is restricted to local usage and you can also read this in the link i provided with my answer to his question. But on the other hand a console application can send a Message with WM_COPYDATA to a Windowed Application, and a Service can also (if interactive) communicate (form service to window) with a Window (i think it should go because it the runs in the default desktop, but i am not sure), at least with SendNotifyMessage(). The Window also could communicate/respond to the service with a User Defined SC Command even, this is a very "limited" communication. My post was "just" a possible "option" for him,... Regards Kerem Signature----------------------- Beste Grüsse / Best regards / Votre bien devoue Kerem Gümrükcü Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied." Kerem, >> This will work until the program is moved to another machine (which >> the OP specified in his original post). [quoted text clipped - 6 lines] > should be clear here. I dont want to go too deep in IPC, you > know what i mean,... I respect that, but it's a lot of code that someone has to write in order to make this happen, when remoting and WCF are out of the box. The only reason I would encourage something like this is if you were communicating with a legacy application which could not be changed. >> Also, the it should be noted that in order to do this, you would have >> to serialize the data into a byte array yourself before sending the data [quoted text clipped - 6 lines] > or unmannaged .NET or whatever allows you casting like dynamic, > static or whatever casting,... You have to be very careful here. In C++, if you had an instance of a class which contained pointers to other sections of memory, and you just did a cast to void, you would end up with invalid addresses in the process that the class was copied to. You need some sort of serialization framework in C++ to traverse all the members of the class and serialize them into a byte array. Just casting to VOID* is a VERY bad idea. With .NET, using serialization, it will traverse the object graph, and serialize it all into a byte array. Of course, Remoting and WCF will do this for you out of the box. > . > > It also fails for service and console applications, it would only be [quoted text clipped - 9 lines] > Window also could communicate/respond to the service with a User Defined > SC Command even, this is a very "limited" communication. Console apps can call SendMessage, but they can't receive messages back, so if you had a console app that had to "listen", then WM_COPYDATA is a bad idea (unless it creates a hidden window). With services, it is even more restrictive, because the service would have to be able to interact with the desktop in order to listen for windows messages, which isn't a good idea either. I'm not sure if a service can call SendMessage though without interacting with the local desktop. > My post was "just" a possible "option" for him,... It's not that it's a bad idea, it just have some severe limitations which need to be acknowledged. Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Regards > > Kerem Hi Nicholas, many roads lead to rome and we could protract this discussion. You say "A", i say "B",...you say "C" and i will say "D", so i hope the OP have had some interessting sights on how this could be done. Sure, if he has the option of some state-of-art or ready solution/method like WPF or Remoting, why he or she should go that way. I would say that i am a experienced C/C++ developer so i know the pittfalls of void pointers and all the stuff that comes with memory allocation and usage, so every aspect of programming has its do's and dont's. Its up to the implementor whether he or she wants speed, security or whatever in her application. We have to accept compromises so it will be done. There is always another way, like there will be always a bug in any code or some sort of weakness in its design, runtime, or whatever! Regards, health and success... Kerem Signature----------------------- Beste Grüsse / Best regards / Votre bien devoue Kerem Gümrükcü Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied." > This will work until the program is moved to another machine (which the > OP specified in his original post). [quoted text clipped - 5 lines] > It also fails for service and console applications, it would only be > good for two windows applications on the same machine. Windows service can create a (hidden) window and pump it's message queue, while it was quite common to do such things year ago (in the DDE era), things have changed since then and there is no reason to go back. Also, with Vista this will fail because a program cannot use SendMessage to send Windows messsages across login sessions. And ... this is not the fastest way to move data across "local" process boundaries, the fastest way is by using Shared Memory (mapped files), WCF implements such a channel, all you need to do is use a NetNamedPipeBinding with a net.pipe:... endpoint, and you get the fastest channel possible using the Framework. Willy. Hi Willy, its been a long time when i used shared memory. I am sure this is also a very fas way to communicate. I am not a friend of hidden windows, so i even dont mentioned that. I cant remember how fast it was compared to WM_COPYDATA. Regards Kerem Signature----------------------- Beste Grüsse / Best regards / Votre bien devoue Kerem Gümrükcü Microsoft Live Space: http://kerem-g.spaces.live.com/ Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "This reply is provided as is, without warranty express or implied." Kerem, While Sendmessage/WM_COPYDATA is really fast when it comes to small messages (max. 2Kb), shared memory is a clear winner when you have to deal with somewhat larger data messages (>8Kb ). Using WCF (NetNamedPipeBinding ) in a service application I was able to pass data structures of 8Kb at a rate of ~70Mb/sec. The highest rate I measured using WM_COPYDATA was ~55Mb/sec using 2Kb messages. Note that whether you like hidden windows or not, Sendmessage/WM_COPYDATA needs a window to send your message at, in a Windows Service (or Console application) there is no other option, after all that's what COM uses under the covers too. Willy. > Hi Willy, > [quoted text clipped - 6 lines] > > Kerem Free MagazinesGet 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 ...
|
Reply to this Message
|
 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.