Community
    • Login

    NPPM_INTERNAL_* commands

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    6 Posts 3 Posters 564 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • moon6969M
      moon6969
      last edited by

      My plugin is renaming a new tab by sending a message to NPP…
      #define NPPM_INTERNAL_SETFILENAME (NPPMSG + 63)

      It seems to work OK, but I was wondering why it’s INTERNAL, and not part of:
      Plugin Communication: Messages and Notifications

      What risk is there when using NPPM_INTERNAL_* messages?

      Cheers.

      1 Reply Last reply Reply Quote 1
      • PeterJonesP
        PeterJones
        last edited by

        @moon6969 said in NPPM_INTERNAL_* commands:

        why it’s … not part of: Plugin Communication: Messages and Notifications

        That part’s easy: When that page was created in the new docset, I just started with the messages and notifications that were already documented in the old set. Since I don’t know the internals well, and don’t know the descriptions / usages of the other messages, I just started there. It was better to have some documentation of them, rather than none. But other messages should be documented eventually, including warning as to risks.

        What risk is there when using NPPM_INTERNAL_* messages?

        I don’t know of the reasons for that “internal” naming scheme, or what risks (if any) are involved. @Ekopalypse or someone else might know better why those are marked _INTERNAL_.

        @Ekopalypse has already suggested and is working on documenting some of the non-_INTERNAL_ message documentation that was lacking. He may be willing to try to document the NPPM_INTERNAL_* as well; I’ve asked over there (and he frequents here as well, so he’ll doubly see it). If he doesn’t have the time or expertise to document those, then someone else (you, maybe?) could volunteer to do it. Anyone can fork the usermanual repo and submit a pull-request – it just needs to be reviewed by the team before it will be incorporated.

        (I would volunteer to do it, but since I’ve never used most of the messages – and probably none that weren’t documented in the old docs – I’d have to dig through source code, see how they’re used, and try to come up with an explanation myself. That would take quite a while, especially since I have multiple Notepad++ related projects taking up a very limited free time for such things.)

        1 Reply Last reply Reply Quote 1
        • pnedevP
          pnedev
          last edited by

          Hi guys,

          They are named _INTERNAL_ because they should not be used externally.
          In other words they are not part of the Notepad++ plugin API (and thus they are not defined in the plugin include file).
          Some may work but it is not guaranteed and you should know what you are doing. Best is to not use them at all.

          BR

          PeterJonesP 1 Reply Last reply Reply Quote 3
          • PeterJonesP
            PeterJones @pnedev
            last edited by

            @pnedev said in NPPM_INTERNAL_* commands:

            They are named _INTERNAL_ because they should not be used externally.
            In other words they are not part of the Notepad++ plugin API …

            Not being part of the API is a valid argument for not using something, because there is no promise of it working a certain way, or continuing to work in the same way in the future.

            But there has to be an underlying reason why those specific messages were marked as internal, and not made part of the API. Do you have insight into that?

            For “rename”, there are two alternatives available to the plugin developer:

            1. use NPPM_MENUCOMMAND with lParam = 41017 to run the File > Rename… menu entry, but that will pop up a dialog box.
            2. use the NPPM_SAVECURRENTFILEAS with lParam pointing to a string containing the full path to the new name, and then deleting the old file

            What is inherently more dangerous about allowing a plugin to rename an open file, using the same message that Notepad++ uses internally to do the rename after popping up the dialog, compared to allowing a plugin to call that dialog for the rename, or doing a save-as and then delete the original? (Or similarly for other internals with workarounds.)

            pnedevP 1 Reply Last reply Reply Quote 2
            • pnedevP
              pnedev @PeterJones
              last edited by

              @PeterJones said in NPPM_INTERNAL_* commands:

              Do you have insight into that?

              There might be different reasons it depends on the implementation.
              For example those messages might be doing only part of the job you think they are doing.
              Those are used to notify the message queue of some event. For instance the file might be renamed from outside or from user action within the editor and in both cases the GUI file tab should be updated with the new name - you might use internal message to notify the GUI about that. The same is true if you do some processing in another thread and it needs to notify the main GUI thread about the job it’s doing.
              Sometimes internally some action might need to be delayed - internal message might help with that because you can post it.

              BR

              1 Reply Last reply Reply Quote 1
              • PeterJonesP
                PeterJones
                last edited by

                @pnedev said in NPPM_INTERNAL_* commands:

                For example those messages might be doing only part of the job you think they are doing.

                That’s probably the best reason right there. :-)

                Thanks for the explanation.

                1 Reply Last reply Reply Quote 1
                • First post
                  Last post
                The Community of users of the Notepad++ text editor.
                Powered by NodeBB | Contributors