.NET

Reply
Valued Mentor
DiningPhilosopher
Posts: 370
Registered: ‎05-06-2012
Message 11 of 14 (199 Views)

Re: Catching Keyboard and Mouse Events

03-08-2013 03:49 PM in reply to: BlackBox_

BlackBoxCAD wrote:

My post was not in any way intended to challenge the request for more information; instead it was simply in the hopes of gaining some level of understanding behind the seemingly absolute response you originally offered.


The OP asked about events, not hooking windows messages.

 

I asked for more specifics because there are ways to handle things like pointer movements in the drawing editor without having to handle low-level input events.

 

 

 

 

Active Contributor
WWFreeman
Posts: 27
Registered: ‎09-02-2012
Message 12 of 14 (196 Views)

Re: Catching Keyboard and Mouse Events

03-08-2013 05:57 PM in reply to: DiningPhilosopher

I actually ended up creating a new modeless window that takes control when focused. Basically got to where layer walk is. Gee, what a test.

 

What prevents me from marking this topic as solved is whether the message filter could be applied application wide. That is, whether a message filter can be added on the plugin initialization.

Valued Mentor
DiningPhilosopher
Posts: 370
Registered: ‎05-06-2012
Message 13 of 14 (185 Views)

Re: Catching Keyboard and Mouse Events

03-09-2013 12:29 AM in reply to: WWFreeman

WWFreeman wrote:

I actually ended up creating a new modeless window that takes control when focused. Basically got to where layer walk is. Gee, what a test.

 

What prevents me from marking this topic as solved is whether the message filter could be applied application wide. That is, whether a message filter can be added on the plugin initialization.


Message filters can be added at any time during a plugin's life.

Active Contributor
WWFreeman
Posts: 27
Registered: ‎09-02-2012
Message 14 of 14 (180 Views)

Re: Catching Keyboard and Mouse Events

03-09-2013 12:39 AM in reply to: DiningPhilosopher

Alright. Although I didn't actually apply that in the end, it is the answer to the initial question:


BlackBoxCAD wrote:

Forgive my curiosity, but while this is no Ctrl+MouseWheel Event handler, what's wrong with DoEvents(), and acedUsrBrk() to catch user input?

 

Quote:

 

"It's fairly common for developers to want to check for user input from time to time during long operations, especially to see whether the user wants to cancel the current activity. In VB you'd use DoEvents() to enable messages to be processed by the application's message loop and in ObjectARX you'd use acedUsrBrk().

So how to do this in .NET?

 

The answer is to use a message filter. This allows us to check on user-input events... we still call DoEvents, as with previous versions of VB, which allows user input events (such as keystrokes) to flow into our message filter function. We can then detect the events we care about, and filter them out, if necessary."

 

http://through-the-interface.typepad.com/through_the_interface/2007/02/index.html



DiningPhilosopher wrote:

Message filters can be added at any time during a plugin's life.


With a really strong notions of dangers of such approach:


DiningPhilosopher wrote:

If you use an IMessageFilter and check if certain keys are pressed, and what is currently happening in AutoCAD, you might be able to do what you need.  You can use System.Windows.Forms.ModifierKeys to check if CTR/SHIFT/ALT are pressed when you see a mouse wheel message, but you'd have to find a combination of keys that aren't used by AutoCAD with mouse wheel activity, if you don't want to step on that.


Thanks everyone.

Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Announcements
Do you have 60 seconds to spare? The Autodesk Community Team is revamping our site ranking system and we want your feedback! Please click here to launch the 5 question survey. As always your input is greatly appreciated.