Hi and I'm working on a WPF fork of NppCSharpPluginPack

Jonathan Johansen

@Mark-Olson Thanks! I have been migrating your code in-place, and I do get the ElementHost’s handle and pass it to Npp.notepad.AddModelessDialog(handle);. I will read through thoroughly - I’m also thinking to check something diagnostic like Spy++?

Jonathan Johansen

Oh, it’s interesting - When I don’t call Npp.notepad.AddModelessDialog(host.Handle);, I can type into the TextBox, but I can’t copy/paste with Ctrl+C/Ctrl+V. When I do call Npp.notepad.AddModelessDialog(host.Handle);, I can’t type in, but I can copy/paste with Ctrl+C/Ctrl+V. Curious.

Jonathan Johansen

The fork is here: https://github.com/framlingham/NppCSharpPluginPack#

Mark Olson

@Jonathan-Johansen said in Hi and I'm working on a WPF fork of NppCSharpPluginPack:

Oh, it’s interesting - When I don’t call Npp.notepad.AddModelessDialog(host.Handle);, I can type into the TextBox, but I can’t copy/paste with Ctrl+C/Ctrl+V. When I do call Npp.notepad.AddModelessDialog(host.Handle);, I can’t type in, but I can copy/paste with Ctrl+C/Ctrl+V. Curious.

OK, that’s really weird. I’ve never had any problem like that before. @rdipardo is kind of a wizard when it comes to the low-level operation of forms; I’m mentioning him in the hopes that he will be able to give you some advice.

pbarney

@Jonathan-Johansen What is the benefit of using WPF instead of what we already have?

rdipardo

@Mark-Olson said in Hi and I'm working on a WPF fork of NppCSharpPluginPack:

@rdipardo is kind of a wizard when it comes to the low-level operation of forms

I’m also unfamiliar with WPF, but I can suggest to @Jonathan-Johansen that hosting the docking form on a WindowsFormsHost might be a better approach. That would at least provide access to a Win32-style window procedure, useful for debugging how (of if) the WM_CHAR message is being handled.

Alternatively, try to expose the window handle of the existing WPF UserControl and pass that to the NPPM_MODELESSDIALOG wrapper instead of the ElementHost (as was tried already ). Or maybe there’s a way for WPF controls to broadcast messages to their child components…🤔?

Jonathan Johansen

@pbarney The benefit of using WPF is that (in my opinion):

I like WPF and have 6 years experience in it, but no experience with WinForms.
It provides strong layout options (e.g. Grid)
It provides flexible data binding
It provides Styles.

Some links from others.

Jonathan Johansen

@rdipardo Thanks for the suggestions! WPF doesn’t have handles for controls like WinForms, and WindowsFormsHost would do the opposite of ElementHost. Thankfully, ElementHost lets you override the WndProc method (which I do here), so I’ll poke around in there for a bit.

Jonathan Johansen

Update: when I inspect the WndProc messages that come through $"{m.Msg} {m.WParam} {m.LParam}", I note these (mostly tangential, but I’d like to document them):

Pressing ‘normal’ keys (e.g. a-z, arrows, 0-9, punctuation) does not send a message to the ElementHostEx, but instead (after I turned the volume up on my laptop), it somehow triggers a bell sound.
Mouse click comes through with 528 513 36634781 and 33 723656 33619969
Switching to another program sends 8 0 0, and switching back to NPP sends 1024 0 0
Pasting into the TextBox works, but does not trigger any messages. Similarly for copying, deleting and backspacing.
Opening the WPF About window sent 8 1116900 0

I’d like to convert the msg id to a string, I’m not familiar with their values. But there still aren’t that many messages, so perhaps I haven’t set up the dock panel correctly. I’ll try the same thing in the existing Forms version and see what comes up for comparison.

pbarney

@Jonathan-Johansen Thanks for the clarification. I don’t develop Windows apps, so I just didn’t know what the two were. After looking at it, it seems that WinForms is more imperative and tightly coupled and WPF is more declarative and modular.

Jonathan Johansen

@pbarney no worries. I think your assessment is probably accurate, but of course you can do amazing things in both.

Jonathan Johansen

Another update: After trying lots of things, running Spy++, Copilot suggested putting a Form around the ElementHost, and I’ve now got (when calling NppFormHelper.RegisterFormIfModeless) it doing something when I press a key, but I don’t think it’s that helpful - For every key press, I get many (>100) and only:

13 = 0xD = WM_GETTEXT WParam is always 256 and LParam is always 737269504944
135 = 0x87 = WM_GETDLGCODE WParam and LParam are always 0 for these.

I found this page about windows message IDs, which was nice, but then I saw that Visual Studio has some special debugging ToString on System.Windows.Forms.Message` that tells you what the ID means when you mouse over during debugging. Nice. But anyway, still no key-specific events / messages.

Well, because keyboard typing works when I don’t send NPPM_MODELESSDIALOG, but cut/paste/delete works when I do, I’m thinking to look at what the message [2036] NPPM_MODELESSDIALOG does internally, to see if I can combine the good sides of both modes for a WPF version.

Coises

@Jonathan-Johansen said in Hi and I'm working on a WPF fork of NppCSharpPluginPack:

look at what the message [2036] NPPM_MODELESSDIALOG does internally

Puts the window handle of the dialog on a list of window handles which are passed, in turn, to IsDialogMessage in the message loop. If that function returns true, no further message processing is done. If all calls return false, the message is passed to TranslateAccelerator, and if that returns false the message is translated and dispatched normally.