I know I can add context menu items via the .xml file. Although if I want to add a plugin function, I'm not sure what ID will I use. They can change if another plugin is installed later.
Is there a way to add context menu items with a windows message?
Best,
-Zobo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a look at Notepad++ and theres really no way to do this. I think this would be interesting as some plugins could make use of the context menu, but it would be extremely hard to distribute a contextmenu.xml file because plugin menu item ids are not always fixed.
I can think of two ways.
The hardcore way, just export the context menu handle (similar to what we do with GetMenu(NppData.NppHandle)).
The other way, export two or more Messages to "add menu item by id" and "remove menu item by id".
The first method offers full control over the menu, while the other prevents programmer screw-ups.
Best regards,
-Zobo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> but it would be extremely hard to distribute a contextmenu.xml file
> because plugin menu item ids are not always fixed.
You've got the point.
Could you give more explanation for your 2 solution?
There may be the third way :
Use the plugin name + function internal ID.
Notepad++ does the binding according the both informations. It's the hardest part since the plugin command ID are assigned dynamically.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 'task' here is to give a plugin developer an option to add items to the Notepad++ context menu. (Currently I'm assuming there is only one Notepad++ context menu, the one that pops up in the editor and is controlled by contextMenu.xml).
Several possibilities come to mind:
1. It is reasonable to say, that only items that are defined in a plugins main manu (FuncList) can be added to the context menu.
1. a. Make a system that makes is possible to predict a FuncItem's ID (like plugin name + internal ID). This would enable the programmer to give specific instructions to the end-user how to add certain elements to the context menu. I think this is interesting in the way that anybody can add anything to to the context menu, but this is not what I'm looking for. I wish to be able to do the "hard work" for the user in the code.
1. b. Notepad++ could handle two new message. NPPM_ADDCONTEXTITEM and NPPM_REMOVECONTEXTITEM. Both would take the DlgID parameter that is returned by FuncItems from Notepad++. It would be the responsibility of Notepad++ to check whether this items are enabled/disabled/grayed at the time of rendering the context menu. A menu separator can also be added like this.
1. c. One perhaps simpler solution would be to extend FuncItems structure and add a flag to it 'include this item in the context menu'. As this is simple, it can easily brake binary compatibility if we just change the FuncItem structure. Perhaps a clever work around could be used, like using one bit from the 'checked' element. But this does not give the developer a choice in what order the items will be added to the context menu.
2. A completely different approach would be to somehow give the plugin developer access to context menu's MenuHandle. This would then enable him to do whatever he wants. I cannot however imagine how one would handle the menu then. And if I understand the context code (I did not have much time to study it), the context menu is actually not a persistent element, but rather gets spawned whenever it's needed. (I could be completely wrong here).
Another thought: Do we enforce some sort of separation between menu items from different plugins? Leave it up to the developers?
Anyway to sum up.
- Make it easy for everybody to add plugin menu items to context menu via contextMenu.xml (plugin name + id)
- Give the developer a way to add elements from the code.
Best regards,
-Zobo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to add to that.
What if you were to create a new function in the DLL, 'getContextItems' (or alike, you get it), which Notepad++ would load if it were existant, but if it fails it assumes the plugin doesnt support it/doesnt need it. This way you can assure maximum binairy compatibility. Then you could add a flag to the array returned (liek FuncItem) what specifies the contextMenuitem is completely new function, or it refers to an index in the FuncItem array.
Storing anything in contextMenu.xml isnt neccessarry that way, the plugin takes care if it.
You can also choose if it were dynamic (function gets called everytime the contextMenu is created) or static where Notepad++ loads the function and initializes everything, after which its own internal memory is used to generate the menu.
The first would probably be ideal for text editing functions (I'd love to see TextFX make use of this, TextFX with context sensitive handling would be perfect)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wouldn't a system like (the shortcuts in) FuncItems be possible? Instead of only requesting FuncItems array, request context menu items, where each item specifies an internal function, a name and maybe what context menu exactly to modify. Notepad++ can use the index in this array to store the configuration of the contextmenu items.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another simplification of this problem could be to add a flag to the FuncItems to include the current item in the context menu.... But this would brake binary compatibility.
-Zobo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know I can add context menu items via the .xml file. Although if I want to add a plugin function, I'm not sure what ID will I use. They can change if another plugin is installed later.
Is there a way to add context menu items with a windows message?
Best,
-Zobo
Currently not. We should talk to Don to extend the XML file functionality.
Best Regards
Jens
I Jens.
I had a look at Notepad++ and theres really no way to do this. I think this would be interesting as some plugins could make use of the context menu, but it would be extremely hard to distribute a contextmenu.xml file because plugin menu item ids are not always fixed.
I can think of two ways.
The hardcore way, just export the context menu handle (similar to what we do with GetMenu(NppData.NppHandle)).
The other way, export two or more Messages to "add menu item by id" and "remove menu item by id".
The first method offers full control over the menu, while the other prevents programmer screw-ups.
Best regards,
-Zobo
> but it would be extremely hard to distribute a contextmenu.xml file
> because plugin menu item ids are not always fixed.
You've got the point.
Could you give more explanation for your 2 solution?
There may be the third way :
Use the plugin name + function internal ID.
Notepad++ does the binding according the both informations. It's the hardest part since the plugin command ID are assigned dynamically.
Don
Hi Don.
The 'task' here is to give a plugin developer an option to add items to the Notepad++ context menu. (Currently I'm assuming there is only one Notepad++ context menu, the one that pops up in the editor and is controlled by contextMenu.xml).
Several possibilities come to mind:
1. It is reasonable to say, that only items that are defined in a plugins main manu (FuncList) can be added to the context menu.
1. a. Make a system that makes is possible to predict a FuncItem's ID (like plugin name + internal ID). This would enable the programmer to give specific instructions to the end-user how to add certain elements to the context menu. I think this is interesting in the way that anybody can add anything to to the context menu, but this is not what I'm looking for. I wish to be able to do the "hard work" for the user in the code.
1. b. Notepad++ could handle two new message. NPPM_ADDCONTEXTITEM and NPPM_REMOVECONTEXTITEM. Both would take the DlgID parameter that is returned by FuncItems from Notepad++. It would be the responsibility of Notepad++ to check whether this items are enabled/disabled/grayed at the time of rendering the context menu. A menu separator can also be added like this.
1. c. One perhaps simpler solution would be to extend FuncItems structure and add a flag to it 'include this item in the context menu'. As this is simple, it can easily brake binary compatibility if we just change the FuncItem structure. Perhaps a clever work around could be used, like using one bit from the 'checked' element. But this does not give the developer a choice in what order the items will be added to the context menu.
2. A completely different approach would be to somehow give the plugin developer access to context menu's MenuHandle. This would then enable him to do whatever he wants. I cannot however imagine how one would handle the menu then. And if I understand the context code (I did not have much time to study it), the context menu is actually not a persistent element, but rather gets spawned whenever it's needed. (I could be completely wrong here).
Another thought: Do we enforce some sort of separation between menu items from different plugins? Leave it up to the developers?
Anyway to sum up.
- Make it easy for everybody to add plugin menu items to context menu via contextMenu.xml (plugin name + id)
- Give the developer a way to add elements from the code.
Best regards,
-Zobo
I'd like to add to that.
What if you were to create a new function in the DLL, 'getContextItems' (or alike, you get it), which Notepad++ would load if it were existant, but if it fails it assumes the plugin doesnt support it/doesnt need it. This way you can assure maximum binairy compatibility. Then you could add a flag to the array returned (liek FuncItem) what specifies the contextMenuitem is completely new function, or it refers to an index in the FuncItem array.
Storing anything in contextMenu.xml isnt neccessarry that way, the plugin takes care if it.
You can also choose if it were dynamic (function gets called everytime the contextMenu is created) or static where Notepad++ loads the function and initializes everything, after which its own internal memory is used to generate the menu.
The first would probably be ideal for text editing functions (I'd love to see TextFX make use of this, TextFX with context sensitive handling would be perfect)
Hi.
I agree, this could also be a nice solution. The question remains, how to influence this menu (how to set disabled and grayed status).
-Zobo
I suppose you can add it as a flag and use the dynamic approach if you were to use a new type of array
Wouldn't a system like (the shortcuts in) FuncItems be possible? Instead of only requesting FuncItems array, request context menu items, where each item specifies an internal function, a name and maybe what context menu exactly to modify. Notepad++ can use the index in this array to store the configuration of the contextmenu items.
Another simplification of this problem could be to add a flag to the FuncItems to include the current item in the context menu.... But this would brake binary compatibility.
-Zobo