retailcoder
commented
7 years ago How much RAM / CPU (horse-power?) do you have?
Because the VBIDE API's CodePane object exposes no events at all, in order to enable/disable menu commands depending on context (current selection), and to be able to update the "context status" in the RD commandbar, we had to register some kind of mouse+keyboard hook (on top of hotkey hooks) to determine when the selection in the code pane is changing.
We pick up left / right mouse button clicks in the code pane:
private void Mouse_RawMouseInputReceived(object sender, RawMouseEventArgs e)
{
if (e.UlButtons.HasFlag(UsButtonFlags.RI_MOUSE_LEFT_BUTTON_UP) || e.UlButtons.HasFlag(UsButtonFlags.RI_MOUSE_RIGHT_BUTTON_UP))
{
OnMessageReceived(this, HookEventArgs.Empty);
}
}And a specific set of keys:
// keys that change the current selection.
private static readonly HashSet<Keys> NavKeys = new HashSet<Keys>
{
Keys.Up, Keys.Down, Keys.Left, Keys.Right, Keys.PageDown, Keys.PageUp, Keys.Enter
};
private void Keyboard_RawKeyboardInputReceived(object sender, RawKeyEventArgs e)
{
// note: handling *all* keys causes annoying RTrim of current line, making editing code a PITA.
if (e.Message == WM.KEYUP && NavKeys.Contains((Keys)e.VKey))
{
OnMessageReceived(this, HookEventArgs.Empty);
}
}In the App class, we handle this MessageReceived hook event by re-evaluating the current code pane selection:
private void _hooks_MessageReceived(object sender, HookEventArgs e)
{
RefreshSelection();
}This is probably the part responsible for the sluggish-ness:
private void RefreshSelection()
{
var pane = _vbe.ActiveCodePane;
{
Declaration selectedDeclaration = null;
if (!pane.IsWrappingNullReference)
{
selectedDeclaration = _parser.State.FindSelectedDeclaration(pane);
var refCount = selectedDeclaration == null ? 0 : selectedDeclaration.References.Count();
var caption = _stateBar.GetContextSelectionCaption(_vbe.ActiveCodePane, selectedDeclaration);
_stateBar.SetContextSelectionCaption(caption, refCount);
}
var currentStatus = _parser.State.Status;
if (ShouldEvaluateCanExecute(selectedDeclaration, currentStatus))
{
_appMenus.EvaluateCanExecute(_parser.State);
_stateBar.EvaluateCanExecute(_parser.State);
}
_lastStatus = currentStatus;
_lastSelectedDeclaration = selectedDeclaration;
}
}Notice that on top of running FindSelectedDeclaration, when ShouldEvaluateCanExecute returns true, then every single menu command runs a number of checks to determine whether it should be enabled or disabled - this normally only takes a few milliseconds per command, but it does add up, and it does mean quite a lot of work is getting done every time the ENTER key is pressed in a code pane.
Merely scrolling shouldn't slow anything down though.
But without all this work, we couldn't tell you that you're selecting a constant, that it's declared in VBE7.DLL under the Strings module, and that it's referenced in 12 places in your code; we would have to leave all menus enabled all the time, and pop message boxes telling you that "the current selection is invalid for the selected command", for example when you click "refactor/encapsulate field" without selecting a field declaration.
We have a plan for v3.0, to literally hijack the code pane, and make it expose proper events and properties - that way we'll know without any key/mouse hooks, not only whether the selection changed, but also whether the code changed. This will open up a whole set of new possibilities, and make everything more efficient.
Falthazar
mattretzer
comintern
argeedblu
Inarion
I'm not sure if its my computer or something else. But whenever rubberduck is loaded it really slows down the VBA IDE. It seems to happen most when I press enter a few times, or when scrolling.
If I unload rubberduck it goes away.