Recent

Author Topic: [Solved] Listview in plugin: enforce an item's redraw if ItemEditor is open  (Read 281 times)

d7_2_laz

  • Hero Member
  • *****
  • Posts: 637
Windows 10 64 bit, Lazarus 4.0.
I just try to add editing capabilities to my custom listview within my Notepad++ (NPP) plugin.
I ran into two issues here:
1) "F2" key (for to engage an EditCaption) cannot be detected in Keydown or Keypress.
2) i get drawing artifacts when the listview editor is open and i mouse-hover along other items.
   For to solve this i'd need to trigger my customdraw routines. But the painting event callback won't be called in this case.

Topic of this thread here is prob #2.
A bit more of details about it: in dark mode, the item's drawing is done via the Windows API managed by NPP. As this doesn't fit my needs at all, i'm using a comprehensive, fully working custom drawing of my listview.

This custom drawing does come out of effect when the listview's item editor is open, what does imply that the listview does not have the focus.

A listview item as it will be drawn now when hovering the mouse outside the item editor will unfortunately generate ugly artefacts; see image (and is, basically, completely different to the styling of my own custom drawing).

I try to enforce my appropriate custum draw here, but as the listview itself does not have the focus when the item editor is open, the custom draw routine will never be called.

Code: Pascal  [Select][+][-]
  1. procedure TMyListview.WndProc( var Message: TMessage );
  2. ....
  3.    if ((Msg = WM_MOUSEMOVE) Or (Msg = WM_MOUSEWHEEL)) then begin
  4.       if Msg = WM_MOUSEMOVE then begin
  5. ....
  6.      // Detect the appropriate condition / item where the mouse is over, and:
  7.      // Diverse tests and measures for to enforce a repaint of the item ("itm" here)
  8.      // - of course not all at once!!  but one after another -:                  
  9.      // if some condition then begin ...
  10.            SendMessage(Handle, LVM_REDRAWITEMS, itm.Index, itm.Index);
  11.         outputdebugstring(pchar('--  trigger repaint  ' + itm.Caption    +  '   index:  ' + inttostr(itm.index) ));
  12.            Refresh;
  13.            Invalidate;
  14.            Self.Update;
  15.            Repaint;
  16.            SendMessage(Self.Handle, WM_ERASEBKGND, 1, 0);
  17.            bRect := Self.BoundsRect;
  18.            InvalidateRect(Self.Handle, @bRect, True);
  19.            InvalidateRect(Self.Handle, 0, True);
  20.            InvalidateRgn(Self.Handle, 0, True);
  21.            Application.ProcessMessages;
  22.  // -->  A debug message within the custom draw event that it is reached won't never be seen
  23.  

Of course: if i set the focus back to the listview, then the painting would work fine, but the editor will be closed immediately when hovering other items, and that's not what is wanted.

Any clever idea (how to tell the listview enforced to repaint a specifc item) would be very welcome  .....
« Last Edit: May 08, 2025, 10:58:41 pm by d7_2_laz »
Lazarus 4.0  FPC 3.2.2 Win10 64bit

d7_2_laz

  • Hero Member
  • *****
  • Posts: 637
Finally i found the reason for the not passed paint message on my own side.
There are a couple of (partially internally called) routines around "OnAdvancedCustomDraw" as well as "OnCustomDrawItem" in play where it turned out that somewhere there was a "if Editing then exit" too much left.
Which was hindering specifically here only when used within the NPP plugin. Removing it immediately removed this custom drawing problem.
Note: the best bugs are the self-produced ones, as easily fixable ..... but sometimes it needs hours to find ...  O:-)
Lazarus 4.0  FPC 3.2.2 Win10 64bit

d7_2_laz

  • Hero Member
  • *****
  • Posts: 637
Addendum:
Meanwhile i found the solution for issue #1:
it was about, that for Listview - as well as Treeview - virtual key F2 (VK_F2) could not be intercepted by OnKeyDown, OnKeyPress and others (eg. wm_char in a window proc) for to invoke EditCaption via pressing F2. Digged some time along the units hierarchy where the "F2" might have gone lost, always suspecting that it could have been eaten up by Notepad++ itself.

And yes: within it's shortcut mapper, the shortcut "F2" is assigned to the functionality "next bookmark".
Removed that mapping for test, and voilà, caption editing via F2 is back again; ready ...
Asked myself, why Notepad++ transfers mappings, that are surely useful for it's own processing, brute-force to plugins actually active.
And, if it is possible to hinder this transfer via an internal notification. Possibly i'll adress these questions within their forum.
Lazarus 4.0  FPC 3.2.2 Win10 64bit

 

TinyPortal © 2005-2018