Getting BufferID from ScNotificationHeader in C#



  • 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!?



  • @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.



  • @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)



  • @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).



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



  • @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?



  • 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.



  • @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?



  • @dinkumoil

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


Log in to reply