Don, could you please make Notepad++ call a plugin's setInfo function before the getFuncsArray? My plugin needs to load its menu item names from an .ini-file, but when getFuncsArray is called I can't request the NPPM_GETPLUGINCONFIGDIR, because I don't yet know the Notepad++ main window handle.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not a good idea to modify the plugins manager to adapte one plugin's specific need, w/o considering that there're other plugins work in the same system.
What you should do is give the dummy name to your menu item. Once you get Notepad++ handle, you modify menu item names by calling
ModifyMenu(MenuHandle, id, MF_BYPOSITION, 0, name);
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's the same thing I need when a plugin's menu is to be created dinamically. I.e. when a plugin reads its menu items from ini-file and you can not foretell how many menu items it will contain - maybe 1, maybe 10, maybe 100...
In such case NPPM_GETPLUGINCONFIGDIR is a limitation, not an advantage.
Another example: you have some plugin hot-key which is used by the plugin in several different places. Thus, this hot-key must be defined inside the plugin to have access to this hot-key from different parts of the plugin. The most intuitional place to store this hot-key is ini-file. And, again, this hot-key must be read from the ini-file before getFuncsArray() is called. So NPPM_GETPLUGINCONFIGDIR is a limitation again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For a truly dynamic menu system you would need a parameter to be passed back to your callback function. Right now every menu item must have its own callback. If you want to have 100 menu items, you must have 100 separate functions compiled into the DLL (and you can't change the number dynamically). Otherwise if you have two menu items and one handler for both, you can't tell which menu item was selected when you're in the handler.
If a callback would accept a plugin-specified integer parameter, we could have a single callback and differentiate between menu items by the parameter value, thus allowing for over 4'000'000'000 menu items per callback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Personally I think that it'd be a nice and regular behaviour if Notepad++ would first supply all the information (setInfo) and then ask questions. Think of it not as of custom-tailoring the plugin manager to this specific need, but as of following the general rule that initialization comes first (i.e. the plugin must be initialized before it is used).
The solution with ModifyMenu looks a bit like a hack, but I agree that it gives more flexibility if one wants to update menu contents after the plugin is loaded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is :
the menu items are initialized in "case DLL_PROCESS_ATTACH:" of DllMain.
Even through I did setInfo immediately in plugins manager:
pi->_hLib = ::LoadLibrary(dllNames[i].c_str());
if (!pi->_hLib)
throw string("Load Library is failed.\nMake \"Runtime Library\" setting of this project as \"Multi-threaded(/MT)\" may cure this problem.");
pi->_pFuncSetInfo = (PFUNCSETINFO)GetProcAddress(pi->_hLib, "setInfo");
if (!pi->_pFuncSetInfo)
throw string("Missing \"setInfo\" function");
pi->_pFuncSetInfo(_nppData);
The segment in "case DLL_PROCESS_ATTACH:" will be executed while calling "LoadLibrary".
So the modification is not really useful, am I wrong?
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me return to this topic, Don. I followed your advice and created a number of predefined dummy menu entries. When the ini-file is loaded, I assign the appropriate text with ModifyMenu and enable the used items. All unused entries have the default "not used" text.
A user of my plugin reported another problem with this approach ( http://sourceforge.net/forum/forum.php?thread_id=1959856&forum_id=482781 ). The problem is that the Shortcut Mapper shows the "not used" as the menu text for all items, and not the current string assigned after initialization.
>The segment in "case DLL_PROCESS_ATTACH:" will be executed while calling "LoadLibrary".
>So the modification is not really useful, am I wrong?
I still want you to call setInfo before all the other. If you do that, I'll just move my initialization into setInfo, and the problem will be solved.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I still want you to call setInfo before all the other.
> If you do that, I'll just move my initialization into setInfo, and the problem will be solved.
I was wrong about that.
Indeed, it will resolve your problem.
I then do setInfo() before getFuncsArray(). It'll work the dynamical menu for your plugin now.
Notepad++ v5 Alpha will be published in few hours, so you can test it with your plugin.
BTW, Insert plugin Web Edition works fine with v4.9.2, but it crashed v5, for a unknown reason.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I then do setInfo() before getFuncsArray(). It'll work the dynamical menu for your plugin now.
Thank you! I will try to release the WebEdit v.1.2 this week.
>BTW, Insert plugin Web Edition works fine with v4.9.2, but it crashed v5, for a unknown reason.
I just tested WebEdit v.1.1 with Npp 5.0 ALPHA, and it works fine. The only plugin that's crashed on startup was Explorer 1.7.2. I submitted the bug report.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion it will be easier to make a change in shortcut view. Please get the names from plugins menu direct. This will help also for the NativeLang plugin.
The plugin changes the menu entries only when the request was issued by other plugins. Therefore all plugins must be loaded and this means setInfo and getFuncsArray were issued before.
If the first suggested implementation by Don works but the ShortCutMapper entries are wrong, this will be the best solution for all plugins and we don't need to change a startup cue that was still working fine.
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this can be done w/o breaking anything, since atm there are no guarantees about any order yet, so adding in some ordering of functions shouldn't break a thing, plugins that rely on this behaviour right now are doing something wrong anyway (this is way less intrusive than the whole "SetWindowLongA breaks Scintilla" issue). ModifyMenu only works to a certain extend. You cannot know for sure which ID is available if you want to add any new command and finding your own menu is pretty tricky and hacky (assuming Plugins is the name or the location is 6 is very bad imho, esp. if translations are used or NppTextFX is adding its own menus).
The callback could work, but that means the structures handed over to Notepad++ have to be changed, which breaks either Notepad++ or all the current plugins, or both. I believe there was a discussion about dynamic menu content some while back, though it was about context menus if I am right.
-Harry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I think this can be done w/o breaking anything,
> since atm there are no guarantees about any order yet,
> so adding in some ordering of functions shouldn't break a thing,
> plugins that rely on this behaviour right now are doing something wrong anyway
Well, it may help a little. You cant blame anyone if their code isnt setup for a setinfo-before-getfuncarray if that isnt implemented yet :).
If it imposes risks then maybe its best left alone, it's your call after all (I shouldn't be in this discussion anyway since I wont make any use of it anytime soon, I think).
Harry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, dynamic menu items could be initialized inside getFuncsArray() if this function would be called after setInfo().
Otherwise there must be complicated code which must determine IDs of dynamic menu items added by AppendMenu() or InsertMenuItem() - because we can't specify these IDs obviously. Or there can be another solution: provide new Notepad++'s message NPPM_GETNEXTMENUITEMID which will return an ID which can be used for new menu item. This solution assumes that Notepad++ will have internal counter of menu item IDs which will be updated each time when when a new menu item is added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don, could you please make Notepad++ call a plugin's setInfo function before the getFuncsArray? My plugin needs to load its menu item names from an .ini-file, but when getFuncsArray is called I can't request the NPPM_GETPLUGINCONFIGDIR, because I don't yet know the Notepad++ main window handle.
Notepad++ 5.0 has setInfo before getFuncsArray, so go and try it out and see if you can get your code to work :)
It's not a good idea to modify the plugins manager to adapte one plugin's specific need, w/o considering that there're other plugins work in the same system.
What you should do is give the dummy name to your menu item. Once you get Notepad++ handle, you modify menu item names by calling
ModifyMenu(MenuHandle, id, MF_BYPOSITION, 0, name);
Don
That's the same thing I need when a plugin's menu is to be created dinamically. I.e. when a plugin reads its menu items from ini-file and you can not foretell how many menu items it will contain - maybe 1, maybe 10, maybe 100...
In such case NPPM_GETPLUGINCONFIGDIR is a limitation, not an advantage.
Another example: you have some plugin hot-key which is used by the plugin in several different places. Thus, this hot-key must be defined inside the plugin to have access to this hot-key from different parts of the plugin. The most intuitional place to store this hot-key is ini-file. And, again, this hot-key must be read from the ini-file before getFuncsArray() is called. So NPPM_GETPLUGINCONFIGDIR is a limitation again.
For a truly dynamic menu system you would need a parameter to be passed back to your callback function. Right now every menu item must have its own callback. If you want to have 100 menu items, you must have 100 separate functions compiled into the DLL (and you can't change the number dynamically). Otherwise if you have two menu items and one handler for both, you can't tell which menu item was selected when you're in the handler.
If a callback would accept a plugin-specified integer parameter, we could have a single callback and differentiate between menu items by the parameter value, thus allowing for over 4'000'000'000 menu items per callback.
May I know where you initialize the menu item?
ie. funcItem[n]._itemName
In "case DLL_PROCESS_ATTACH:" of DllMain?
Don
Either there or in the getFuncsArray itself.
Personally I think that it'd be a nice and regular behaviour if Notepad++ would first supply all the information (setInfo) and then ask questions. Think of it not as of custom-tailoring the plugin manager to this specific need, but as of following the general rule that initialization comes first (i.e. the plugin must be initialized before it is used).
The solution with ModifyMenu looks a bit like a hack, but I agree that it gives more flexibility if one wants to update menu contents after the plugin is loaded.
The problem is :
the menu items are initialized in "case DLL_PROCESS_ATTACH:" of DllMain.
Even through I did setInfo immediately in plugins manager:
pi->_hLib = ::LoadLibrary(dllNames[i].c_str());
if (!pi->_hLib)
throw string("Load Library is failed.\nMake \"Runtime Library\" setting of this project as \"Multi-threaded(/MT)\" may cure this problem.");
pi->_pFuncSetInfo = (PFUNCSETINFO)GetProcAddress(pi->_hLib, "setInfo");
if (!pi->_pFuncSetInfo)
throw string("Missing \"setInfo\" function");
pi->_pFuncSetInfo(_nppData);
The segment in "case DLL_PROCESS_ATTACH:" will be executed while calling "LoadLibrary".
So the modification is not really useful, am I wrong?
Don
Let me return to this topic, Don. I followed your advice and created a number of predefined dummy menu entries. When the ini-file is loaded, I assign the appropriate text with ModifyMenu and enable the used items. All unused entries have the default "not used" text.
A user of my plugin reported another problem with this approach ( http://sourceforge.net/forum/forum.php?thread_id=1959856&forum_id=482781 ). The problem is that the Shortcut Mapper shows the "not used" as the menu text for all items, and not the current string assigned after initialization.
>The segment in "case DLL_PROCESS_ATTACH:" will be executed while calling "LoadLibrary".
>So the modification is not really useful, am I wrong?
I still want you to call setInfo before all the other. If you do that, I'll just move my initialization into setInfo, and the problem will be solved.
... or into getFuncsArray, as dv__ suggested.
> I still want you to call setInfo before all the other.
> If you do that, I'll just move my initialization into setInfo, and the problem will be solved.
I was wrong about that.
Indeed, it will resolve your problem.
I then do setInfo() before getFuncsArray(). It'll work the dynamical menu for your plugin now.
Notepad++ v5 Alpha will be published in few hours, so you can test it with your plugin.
BTW, Insert plugin Web Edition works fine with v4.9.2, but it crashed v5, for a unknown reason.
Don
>I then do setInfo() before getFuncsArray(). It'll work the dynamical menu for your plugin now.
Thank you! I will try to release the WebEdit v.1.2 this week.
>BTW, Insert plugin Web Edition works fine with v4.9.2, but it crashed v5, for a unknown reason.
I just tested WebEdit v.1.1 with Npp 5.0 ALPHA, and it works fine. The only plugin that's crashed on startup was Explorer 1.7.2. I submitted the bug report.
In my opinion it will be easier to make a change in shortcut view. Please get the names from plugins menu direct. This will help also for the NativeLang plugin.
The plugin changes the menu entries only when the request was issued by other plugins. Therefore all plugins must be loaded and this means setInfo and getFuncsArray were issued before.
If the first suggested implementation by Don works but the ShortCutMapper entries are wrong, this will be the best solution for all plugins and we don't need to change a startup cue that was still working fine.
Jens
I think this can be done w/o breaking anything, since atm there are no guarantees about any order yet, so adding in some ordering of functions shouldn't break a thing, plugins that rely on this behaviour right now are doing something wrong anyway (this is way less intrusive than the whole "SetWindowLongA breaks Scintilla" issue). ModifyMenu only works to a certain extend. You cannot know for sure which ID is available if you want to add any new command and finding your own menu is pretty tricky and hacky (assuming Plugins is the name or the location is 6 is very bad imho, esp. if translations are used or NppTextFX is adding its own menus).
The callback could work, but that means the structures handed over to Notepad++ have to be changed, which breaks either Notepad++ or all the current plugins, or both. I believe there was a discussion about dynamic menu content some while back, though it was about context menus if I am right.
-Harry
> I think this can be done w/o breaking anything,
> since atm there are no guarantees about any order yet,
> so adding in some ordering of functions shouldn't break a thing,
> plugins that rely on this behaviour right now are doing something wrong anyway
The thing is I don't see why I should take a risk to change it, if I don't gain the advantage.
See :
https://sourceforge.net/forum/message.php?msg_id=4846639
Don
Well, it may help a little. You cant blame anyone if their code isnt setup for a setinfo-before-getfuncarray if that isnt implemented yet :).
If it imposes risks then maybe its best left alone, it's your call after all (I shouldn't be in this discussion anyway since I wont make any use of it anytime soon, I think).
Harry
Actually, dynamic menu items could be initialized inside getFuncsArray() if this function would be called after setInfo().
Otherwise there must be complicated code which must determine IDs of dynamic menu items added by AppendMenu() or InsertMenuItem() - because we can't specify these IDs obviously. Or there can be another solution: provide new Notepad++'s message NPPM_GETNEXTMENUITEMID which will return an ID which can be used for new menu item. This solution assumes that Notepad++ will have internal counter of menu item IDs which will be updated each time when when a new menu item is added.