Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determining a selection or module content change #1143

Closed
ThunderFrame opened this Issue Feb 24, 2016 · 4 comments

Comments

Projects
None yet
5 participants
@ThunderFrame
Copy link
Member

ThunderFrame commented Feb 24, 2016

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

This comment has been minimized.

Copy link
Member Author

ThunderFrame commented Feb 25, 2016

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

@retailcoder

This comment has been minimized.

Copy link
Member

retailcoder commented Feb 25, 2016

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

This comment has been minimized.

Copy link
Member Author

ThunderFrame commented Feb 25, 2016

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

@comintern

This comment has been minimized.

Copy link
Contributor

comintern commented Dec 20, 2018

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

@comintern comintern closed this Dec 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.