SCN_UPDATEUI populating notification.Updated

[vinsworldcom]

trafficstars

I have:

        public void OnNotification(ScNotification notification)
        {
            if (notification.Header.Code == (uint)SciMsg.SCN_UPDATEUI)
            {
                if ((notification.Updated & (uint)SciMsg.SC_UPDATE_V_SCROLL) == (uint)SciMsg.SC_UPDATE_V_SCROLL)
                {
...

Trying to match if the notification updated field is equal to SC_UPDATE_V_SCROLL.

Debugging shows me that when vertically scrolling, the value of notification.Updated is 0. Running a PythonScript to show me the value it sees in the SCN_UPDATEUI message, updated field during vertical scrolling - it correctly shows 4.

It could be:

1. I don't understand this interface, am not that familiar with C# and am doing it wrong. Please provide a correct working example if so.
2. Indeed there is a bug and the Updated field of ScNotification is not getting updated properly during SCN_UPDATEUI notification events.

Cheers.

[rdipardo]

2. Indeed there is a bug and the Updated field of ScNotification is not getting updated properly during SCN_UPDATEUI notification events.

Most likely, and I would suspect the alignment of the ScNotification structure.

The AnnotationLinesAdded field is supposed to be the size of a Sci_Position, i.e., 8 bytes in 64-bit mode. It's currently an int, a.k.a. a CLR Int32 struct.

Notice that the Updated field comes immediately after AnnotationLinesAdded. Scintilla's (proper) alignment would give AnnotationLinesAdded enough room to completely swallow the Updated field.

1) Scintilla alignment (x86_64)                     2) .NET plugin alignment
+ __________________________________ +              + _______________________________ +
|  .....                                            |  .....                          |
|  AnnotationLinesAdded  1st 4 bytes |              |  AnnotationLinesAdded           |
|                        2nd 4 bytes |  overlap ->  |  Updated                        |
|  Updated                           |              |  ListCompletionMethod           |
|  ListCompletionMethod              |              |  CharacterSource                |        
|  CharacterSource                   |              + _______________________________ +
+ __________________________________ +

Fun experiment: debug a 64-bit build of your .NET plugin, but this time inspect the value of the ListCompletionMethod field. Is it 4 when you expect the Updated field to hold that value?

[vinsworldcom]

@rdipardo so excuse the silly simple question, but I'm just not that familiar with C#. Is this as easy as just changing the ScNotification structure in 'PluginInfrastructure\Scintilla_iface.cs' to the correct sizes? Or is there other compiled DLLs as part of this plugin builder that need to be recompiled / changed too?

Cheers.

[rdipardo]

@vinsworldcom,

Is this as easy as just changing the ScNotification structure in 'PluginInfrastructure\Scintilla_iface.cs' to the correct sizes?

I seem to have pulled it off with only trivial changes to the struct definition, so yes: https://github.com/vinsworldcom/NppMarkdownPanel/pull/2

[vinsworldcom]

I seem to have pulled it off with only trivial changes to the struct definition, so yes: vinsworldcom/NppMarkdownPanel#2

You read my mind. I have a primitive synchronize on vertical scroll implemented in my fork that I was trying to clean up before submitting a PR to NppMarkdownPanel. Looks like you beat me to it!

Cheers.

[rdipardo]

@vinsworldcom,

You read my mind.

I just followed the linked issue to this thread and put 2 and 2 together. Happy to do it, since frankly it's the .NET plugin developers who need the most help.

Consider that the last major change to Scintilla's notification struct was in v4.1.4, which would be N++ 7.7. Just one example of the horrendous bit rot you have to contend with.