Plugin; irregularities with inplace editors closure

[Coises]

@klaus101 said in Plugin; irregularities with inplace editors closure:

would you differentiate between WM_KILLFOCUS and NM_KILLFOCUS regarding their potential here?

Yes.

WM_KILLFOCUS is sent to the window that is losing focus with the window handle of the window that will gain focus.

NM_KILLFOCUS is sent to the parent window of a control that has lost focus, and it identifies the control that lost focus.

To use WM_KILLFOCUS you would need to subclass the control in question (the tree view or list view) and react to that message in your custom window procedure. To use NM_KILLFOCUS you would recognize it within the WM_NOTIFY case in your dialog procedure.

I don’t have enough experience with tree view or list view controls to know which, if either, might solve your problem. But they are very different.

[rdipardo]

@klaus101 said in Plugin; irregularities with inplace editors closure:

3. Could maybe someone replicate if this does occur also with Delphi?

No, I can’t, assuming I understand what you’re referring to.

First, I downloaded a current snapshot of the latest template sources from https://bitbucket.org/rdipardo/delphiplugintemplate/downloads

• I changed the TreeView’s ReadOnly property to make it editable:

--- a/Source/Forms/helloworlddockingforms.lfm
+++ b/Source/Forms/helloworlddockingforms.lfm
     Height = 146
     Top = 8
     Width = 238
-    ReadOnly = True
+    ReadOnly = False
     ScrollBars = ssVertical
     TabOrder = 2
     Items.Data = {

• I built the plugin and placed it in the load path of a compatible N++ version.

• I clicked the toolbar button to show the docking form.

• I double-clicked a list item and typed into it.

• With focus still on the item, I moved the mouse pointer into the buffer window, then clicked.

• Focus moved into the buffer window:

I did however notice a different issue, namely, when editing a TreeView item while the form is “floating” (i.e., dragged into the buffer window area).

In that scenario, the list item’s edit control cannot be unfocused at all; it hangs up the message loop until the “Not responding” system dialog appears and you request a hard shutdown.

The solution probably involves some variation of Damjan Cvetko’s famous hack of toggling the WS_EX_CONTROLPARENT attribute flag in the form’s WM_NOTIFY procedure. It’s just a matter of finding out whether WS_EX_CONTROLPARENT needs to be set or cleared, and in response to which DMN_* message.

---

Moderator Note

A better place to open this topic would have been the plugin template’s bug tracker.

After some investigation, however, it seems the underlying issue is the N++ Docking Manager’s overbearing behavior in relation to docking forms that it sees as “child” dialogs, which can break dialogs that have their own complicated hierarchy of child components, as discussed in more detail here.

For that reason I would not penalize the OP for straying off-topic. But only this time.

[klaus101]

To the moderator: Which topic exactly to you mean? The latter about the floating window?.

For myself i intentionally did not post in the plugin’s template bugtracker, because i never assumed i’d have a problem with this template’s demo program here.
I had not been sure, is it a general issue with the NPP interface, or do i have a problem with the Lazarus code in this special case (therefore interest in comparison with Delphi or other languages).

So, would it be possible for me to send one answer to Coises as well as to rdipardo tomorrow? I think most had been clarified. Thank your!

[ryangray01]

Re: Plugin; irregularities with inplace editors closure
That’s a really interesting observation. I’ve faced similar quirks with inplace editor behavior in plugin environments, especially when dealing with embedded controls inside docking panels. It almost feels like the message loop or focus chain behaves differently compared to standalone apps — possibly because the parent window (like NPP) handles focus in a non-standard way. I haven’t tested this exact case in Delphi yet, but it sounds replicable. I’d guess it might have to do with how modal input or focus loss is propagated — or not — when nested within another host application. Have you tried subclassing the editor’s parent to monitor focus loss explicitly?

[klaus101]

@Coises

To use WM_KILLFOCUS you would need to subclass the control in question (the tree view or list view) and react to that message in your custom window procedure

Yes, that’s already the case (have a subclassed windows procedure for, eg., the treeview), and here the treeview itself actually is notified via WM_ messages. So one knows that the treeview had lost the focus … to it’s overlaying child window “edit control”, and this is no surprise …

NM_KILLFOCUS is sent to the parent window of a control that has lost focus. … To use NM_KILLFOCUS you would recognize it within the WM_NOTIFY case in your dialog procedure

Well … understood. NM_KILLFOCUS would be one possible notification via/beyond WM_NOTIFY. One might intercept it here, and by that it can be known that one of the treeview’s children lost it’s focus too (and to which hwndFrom), and this is the essential part to know.

But … (and this surprised me too now!): the LCL treeview (at least mine) doesn’t receive such WM_NOTIFY (and then herein nm_killfocus).
Different from other controls where it can be intercepted. Imo one needs to know here that in Lazarus the treeview is purely LCL-written, other than, e.g., the listview, which is based on the windows common controls, and this might be a reason.
Afaik, in Delphi (at least in Delphi7 as i know from earlier days) the treeview is based on the windows control too.

With other words: at least for the treeview i’d need to pursue the “MouseLeave” way, which delivers the same information needed (treeview lost focus onto a control even outside the node editor, and which one).

[klaus101]

@rdipardo Thank you for having tested!
It’s a bit hard to identify in the gif screen cast when/where a click happens. So only for confirmation: (regarding a docking, not floating window here):
when you write/type into the npp editor buffer, the treeview’s node editor stays open, but when you click into it, it correctly closes?
The latter would tell me that i encountered a Lazarus flaw here, and i’d indeed need a LCL fix or such workaround as described.

[PeterJones]

@ryangray01 ,

Piecing together random snippets from previous posts makes you look like an out-of-date generative AI. You might try putting more original content in your posts that hasn’t been covered by existing discussion, or you will find yourself banned for posting AI nonsense (which isn’t allowed in this forum)

[klaus101]

@PeterJones ???

[PeterJones]

@klaus101 ,

Look up a few posts. You will see a post by the user I was replying to. (From your perspective, it got buried a few posts above the most recent post, because they posted during a time when there was no moderator available to approve posts in the queue. That sometimes happens, because while we have moderators spread across the globe, we have lives outside of this Community, and so sometimes posts go up to even 6-8 hours without being approved; when they do finally get approved, they go into the discussion at the timeslot in the conversation when they were submitted, not the time where they were finally approved.)

[klaus101]

@PeterJones Peter, oh sorry - i hadn’t realized it this morning in the hurry, my bad!