Determining a selection or module content change

[ThunderFrame]

I recall seeing references to key hooks, presumably to catch keyboard shortcuts, but also to capture edits to a module and/or changes to the current text selection. While key hooks will need to be the approach for keyboard shortcuts, there are a number of downsides to keyhooks for tracking code and selection changes:

1. Code edits can be performed without keystrokes (eg. Copy/Paste, Mouse-drag, Event handlers, interface implementations, Replace/Replace All, VBE and 3rd party addins, etc)
2. Selection changes can be made without keystrokes (eg. Mouse, Code-Pane dropdowns, context menus, menus etc.)
3. If you have multiple codepanes open, then you are processing a lot of messages.

I've done some preliminary work to look at alternatives to keyhooks for tracking edits and selections...

All code panes are MDI child windows, so the MDIClient window sends and receives a number of messages. The WM_MDIGETACTIVE message is sent and received with details of the active MDI Child window, every time the MDI Client needs to update.

A change to the Code Pane, results in a WM_MDIGETACTIVE message in the MDI Client Window, and those Code Pane *changes" seem to include:

1. Change of selection, or cursor location
2. Change of content from keyboard, mouse and other actions
3. Change of selection when used with Find Next or Replace (Replace All seems to operate differently, by editing the content of the modules themselves, rather than the code panes. That is Replace All will make edits in modules, even if they're not open in a code pane)

If we track these messages, we're effectively getting an event that tells us that a particular MDI child window has potentially changed in some way, and we only have to listen on a single hWnd.

On every WM_MDIGETACTIVE message, by comparing the last known selection with the new selection, we could determine the changes?

[ThunderFrame]

Need to be mindful of messages while in run mode. IE. They increase in volume, and edits aren't occurring.

[retailcoder]

I don't know about this. It's yet another hook and, really, quite a lot of overhead to cover what's essentially an edge case: there's always the refresh button to trigger the parser and keep everything in sync.

[ThunderFrame]

Agreed, it's a lot of testing too. I just wanted to document the approach, as it seems like itwould work, and be the least complicated approach. Maybe 3.0/4.0....

[comintern]

This is currently handled through VbeEvents and subclassing. Closing as obsolete.