tags:

views:

144

answers:

4

Hello,

I am not sure about how to do it, and what to search for...

I want a simple executable which "raises an event". I know, this sound crazy and is most likely described with the wrong terms. Lets go back a few steps and describe the scenario:

I just bought a nice Wacom Pen + Touch. I also have a Logitech MX Laser Mouse with some fance buttons. And my keyboard has some nice functional buttons too... So a lot of ways to control stuff, and I tend to do "everything" in .NET and WPF (in the hopefully near future)..

The problem is however, I do not have the time to dig into each of the drivers to make sure they work "natively" with .NET. But most configure apps (wacom, setpoint) allow the assignment of applications to buttons.

So my idea is a simple executable compiled only for one purpose: Raising an event when called. Something like "WacomButton1Pressed.exe".

I know WCF but I think this is overkill, the app should not need to connect to a webservice. Is there any other "loosly coupled" model in .NET which allows me to subscribe to "global events". I know a little bit about application domains, for starters assume everythings runs at the lowest security level (GAC switched off, I am admin, Windows 7)...

Is there some "global" event broker (comparable to the EventAggregator in PRISM e.g.) on operation system level where I can raise and listen to events. If not, any idea for a workaround which takes little to none "detail knowledge" (this is kind of play around low priority, so on the one side, I want to do it "right", on the other side, I can't spend to much time for basic research :-)

Thanks for any tips, Chris

PS: Search terms are welcome, Event is not the most google friendly word :-)

A: 

Pure speculation... You might be able to do this with WMI .. Subscribe to certain WMI events and, when fired, respond to them with your app in some way?

Jacob G
+2  A: 

I know you already considered and dismissed WCF, but I would advice you to reconsider. WCF is so much more than web services - basically, it should be your default choice of a communication stack as soon as you need to talk across processes (whether that is internally on the same machine, or across machine boundaries).

You can use named pipes with WCF, which is what I would do in this scenario.

Mark Seemann
I'll second that...WCF + named pipes sounds like a good solution.
Joseph
Ok, I think I will play around with WCF a little more. It just seemed overkill (I had the impression the "server discovery" takes its time), but this may be due to debugging builds and other stuff. Will try a small "ping" app, lets see how fast it is (latency at the beginning will be the cruical part)...
Christian
Maybe I misunderstood the question. I thought that he wanted to respond to any event from any peripheral regardless of what the user is currently doing. So, if he is in Photoshop and the user scrolls his MouseWheel, his app should get the event.
Jacob G
Yes, in this particular question I was only concerned with "raising" global events. What you mention is a little bit more in this direction: http://stackoverflow.com/questions/1511682/detect-stylusdown-outside-app-window (related but different question)
Christian
@Christian: It can be pretty fast over named pipes, but there may be a small overhead depending on your exact scenario. The way I understood your question I would say you could make it work pretty smoothly, but I may have misunderstood something.
Mark Seemann
I just had a completely different idea that may or may not fit the scenario better. See my other answer for more details :)
Mark Seemann
A: 

WCF is not just web services, as others have said, and is probably the most appropriate .NET technology to use for messaging solutions.

I would suggest:

  • Define a simple WCF service and operation contract to handle the event
  • Create a simple console app that is a WCF service host, and implements the contract; when getting a message, it can pop open a messagebox or do whatever you want. It doesn't have to be a console app, it can be a WPF, Winform, Windows service, whatever is the most appropriate -- any .NET executable can be a WCF service host
  • Create your "WacomButton1Pressed.exe" that instantiates a proxy (or uses ChannelFactory) to send the message to your listener

Then just wire up your mouse/input device buttons to call the app (if it is a console app you may even be able to pass command line parameters using the configuration tool -- i.e. "WacomButtonPressed.exe -button1"

When you want to run, start up the listener, then click away and it should send the messages.

Guy Starbuck
A: 

Besides WCF, Windows actually has another 'global' event broker: MSMQ

If you set up a non-transacted private queue, it can handle thousands, if not tens of thousands messages per second if they are small messages (as I get the impression that they will be here).

Then you just need to have another app polling the queue.

There's an easy-to-use .NET API to MSMQ.

The only downside is that you will need to install the MSMQ Windows service (it's a free part of every version of Windows since Windows 2000, but is not installed by default).

Mark Seemann
Also interesting, definitly worth a look. Heard the term before, but never went into it... Thanks
Christian