Getting BufferID from ScNotificationHeader in C#

moon6969

I’m having trouble marshalling the bufferID from the NPPN_* messages.

The code in question is based on NotepadPlusPlusPluginPack.Net …

[StructLayout(LayoutKind.Sequential)]
    public struct ScNotificationHeader
    {
        public IntPtr hwndFrom; 
        public IntPtr IdFrom;
        public uint Code;       
    }
    [StructLayout(LayoutKind.Sequential)]
    public struct ScNotification
    {
        public ScNotificationHeader Header;
        ....

ScNotification notification = (ScNotification)Marshal.PtrToStructure(notifyCode, typeof(ScNotification));
Console.Write($"{notification.Header.Code} = {notification.Header.hwndFrom}, {notification.Header.IdFrom}")

This gives output for 1017 (NPPN_DOCORDERCHANGED)…
1017 = 1, 150324816

No matter which NPPN_* message I look at, I can’t make sense of the idFrom field.

This is the underlying NPP structure from Scintilla.h…

struct Sci_NotifyHeader {
	/* Compatible with Windows NMHDR.
	 * hwndFrom is really an environment specific window handle or pointer
	 * but most clients of Scintilla.h do not have this type visible. */
	void *hwndFrom;
	uptr_t idFrom;
	unsigned int code;
};

My Marshalling knowledge is obvioulsy a little rusty… can someone please help me understand this!?

dinkumoil

@moon6969

If there is a Scintilla text buffer related to the notification, the idFrom member contains its id. The id can be used for example in calls to NPPM_GETPOSFROMBUFFERID, NPPM_GETFULLPATHFROMBUFFERID or NPPM_RELOADBUFFERID (and others).

You can read the documentation of the NPPN_... notifications in the new Notepad++ manual.

moon6969

@dinkumoil: Thanks for reply.

The docs indicate that NPPN_DOCORDERCHANGED has the “from” BufferID in idFrom, and the “to” BufferID in the hwndFrom field.
The 1 in my example is the correct “to Id”, but I was expecting a 3 in “from Id”, and am getting a very large number instead!
1017 = 1, 150324816

I assume it’s a pointer to something in unmanaged (NPP) memory space, but I can’t figure out how to get it in C#.

(edit: from/to wrong way round)

dinkumoil

@moon6969 said in Getting BufferID from ScNotificationHeader in C#:

The docs indicate that NPPN_DOCORDERCHANGED has the “from” BufferID in idFrom, and the “to” BufferID in the hwndFrom field.

You must have missed something, the doc states:

NPPN_DOCORDERCHANGED
hwndFrom: newIndex
idFrom: bufferID
Notifies plugins that document order is changed,
bufffer bufferID having index newIndex.

So, your result 1017 = 1, 150324816 means that Scintilla text buffer with the id 150324816 now has index 1. Since I’m not sure if buffer indices are 0 or 1 based, I can not tell whether the document now is in the first (leftmost) or in the second tab (counted from left).

moon6969

Thank you - my mistake…
I didn’t appreciate that BufferID is not an index 💡!!

Ekopalypse

@moon6969 @dinkumoil

I’m confused because for me it looks like NPPN_DOCORDERCHANGED
reports the old index.

before move new1 is index 0
 [('new 1', 36961968, 0, 0), ('new 2', 113485648, 1, 0)]

move and received  {'code': 1017, 'bufferID': 36961968, 'newIndex': 0}

check after move shows new index is 1
after [('new 2', 113485648, 0, 0), ('new 1', 36961968, 1, 0)]

You do have different results?

Ekopalypse

ok, I guess I found the issue.

When using View->Tab->Move Tab Forward/Backward
the the newIndex is reported but when using mouse to drag to new position, then oldIndex is reported.
I think this is a bug and not intended.

dinkumoil

@Ekopalypse said in Getting BufferID from ScNotificationHeader in C#:

When using View->Tab->Move Tab Forward/Backward
the the newIndex is reported but when using mouse to drag to new position, then oldIndex is reported.

Yes, I can confirm that. Would you mind to file an issue in the bug tracker?

Ekopalypse

@dinkumoil

:-D just done, and I assume code part has been identified as well.
Thx for confirming.