views:

52

answers:

3

I'm currently developing a silverlight application with prism. From this application I need to be able to send a command or keystrokes to a client-side application. What is the best way to accomplish this?

Things I'm considering:

Javascript can use an ActiveX object to use DDE. (Limits to IE only)

Javascript can interact with a java applet to use DDE. (Have to deal with signing the applet appropriately)

Silverlight 4 can access COM objects if running Out of Browser. (I would like to avoid running out of browser)

Are there any other options that I am overlooking?

A: 

It's an overkill but if the client application is under your control you could just host a small http container and post to localhost:port from Silverlight :)

Bogdan
A: 

Try using a WCF Duplex service

Pushing Data to Silverlight from WCF Duplex Service

Stephan
Isn't this for Server to SL Client interaction, not SL Client to Client?
stocherilac
Is this SL to SL or SL to .NET or what? If the client side app is .NET you could host a use a duplex service as part of your client side app. It might be a little heavy but it does a great job of abstracting the interaction between the two clients.
Stephan
In theory, you could host the WCF duplex service in an executable that also resided on the client, but I agree, that seems like overkill. It highlights the idea, though, that there are effectively four ways of "reaching outside the sandbox" with Silverlight: (1) Javascript; (2) WCF; (3) Sockets; (4) COM Interop (when running OOB). If SL is running in-browser, you could use any of the first three methods in some fashion to communicate with other processes running on the box -- you just need to have enough control over those processes to let Silverlight in when it knocks.
Ken Smith
@Stephan the client side app I'm am trying to reach for all intents and purposes I do not have control over. The best way to think of it would be an application that accepts CLI type commands.
stocherilac
+1  A: 

In addition to the other suggestions, if you use something like Firebreath to develop the sort of ActiveX control you mention above, you get an effectively identical NPAPI interface for your control for free. This would allow you to create one control in native (C++) code that would then work across all major browsers; and you could then talk to that control from Silverlight via its JavaScript bridge. Of course, any application that depends on sending keystrokes to another application is going to be pretty brittle, so you'll have to design your interface pretty well to ensure that things don't go suddenly haywire on you when the other application you're controlling hiccups.

Ken Smith
So... im a bit confused here. You can use Firebreath to wrap an ActiveX control so that it can be used in any browser?
stocherilac
Not quite - you write your control using the Firebreath framework, and when you compile your control, it generates both an ActiveX interface for IE (using ATL behind the scenes) and an NPAPI interface for everything else. The same DLL hosts both interfaces, and once it's installed and registered, the same JavaScript will work on both IE and Firefox and Chrome. Make sense? The only downside (such as it is) is that Firebreath requires that you use CMake as your build system for the control, which is a bit of a pain, but probably worth it for what you get.
Ken Smith
Hmm yes that makes sense. Definitely a viable option, +1. I'll need to decide if that is better than making a java applet. Thanks.
stocherilac