Yes I know that I should make v3.3 available as soon as possible.
But I prefer to have the plugin system done so that there's no need to recompile the plugins for each new Notepad++ version.
The new added feature let the plugins process the Npp messages.
For the moment, only 5 messages are available :
WM_GETMINMAXINFO, WM_SIZE, WM_MOVE, WM_MOVING and WM_SIZING.
I will make the messages accessible little by little, according to the need of plugin development.
If you need more messages, just let me know.
In order to be compatible withe the future v3.3, you have to add this line in "PluginInterface.h" file
extern "C" __declspec(dllexport) void messageProc(UINT Message, WPARAM wParam, LPARAM lParam);
And define this function (just give an empty dfinition for the moment) in your sourc file.
>> So: a notification when file changes mode,
>Considering the performance issue, there's few chance that I'll make it available, but I'll think about it.
Hmm, yes, thinking of it, perhaps not all plugins are interested in all notifications.
Have you thought of a publish/subscribe system? Ie n++ publishes a lot of events,
and if a certain plugin want the event, it has to subscribe to it, by sending a subscribe message.
The current ones could be 'auto-subscribed' in order not to break current plugins?
Anyway, I got your answer, and won't be nagging you about this again
>> and a way of asking what mode the file is in would be great :-)
>You can get the current view from notepad++ handle,
> the send the current scintilla view the message to get knowledge if read only mode is enabled.
Could you please elaborate a little bit on this?
I see NPPM_SETMENUITEMCHECK, which sets/unsets check on menu, but I don't see
NPPM_GETMENUITEMCHECK which would be perfect.
I see NPPM_GETMENUHANDLE, but it gives me the Plugins menu handle, insted of Edit menu
I do not see how I'd go about to ask a menuitem for its checked status.
Thanks for the answers
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This function needs to return a value, just like the equivalent windows function. At this time you may have no use for a return value so just tell everyone to always return the same value. Then later when we think of something we can do with a return value it will be there ready for use and won't require another interface change.
I also wonder why this is needed. Subclassing can do everything this can do, and a lot more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> This function needs to return a value, just like the equivalent windows function.
Then it'll return LRESULT.
> I also wonder why this is needed. Subclassing can do everything this can do, and a lot more.
My intention is make easier the life of plugin authors, so they don't need to subclass Notepad++ handle.
OTOH, it can avoid to browser in the Notepad++ source code to see what it does. In long term, I will make Notepad++ messages and relative doc available for the plugin development.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi donho, i'm bumping this old thread since i'm developing a new HTML plugin (another one :) ) that will do tag matching, tag inserting, and whatever else will come to my mind.
Are you still accepting requests for adding new messages to the plugin callback, or should i start thinking of subclassing? Anyway, the message i would need is WM_COMMAND, to handle a popup menu.
Thank you,
FC
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right! I want to display a popupmenu through a function of my plugin, to show all tags available for insertion, and i was thinking to handle the result from that menu through the message queue.
But there's the TPM_RETURNCMD flag, that makes the TrackPopUpMenu function return what i need in a very simple way.
Thank you for bringing me on the right way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, so is it appropriate to ask for another message/notification in this thread?
I'd _really_ like to know when the user changes a file from read/only to read/write
and vice versa. I finally found out a workaround to change the file state via
calling menu_handling functions. But that only toggles read/write - read/only.
I have no way of knowing what I am toggling _to_, unless I keep state of each open file.
So: a notification when file changes mode, and a way of asking what mode the file is in
would be great :-)
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes I know that I should make v3.3 available as soon as possible.
But I prefer to have the plugin system done so that there's no need to recompile the plugins for each new Notepad++ version.
The new added feature let the plugins process the Npp messages.
For the moment, only 5 messages are available :
WM_GETMINMAXINFO, WM_SIZE, WM_MOVE, WM_MOVING and WM_SIZING.
I will make the messages accessible little by little, according to the need of plugin development.
If you need more messages, just let me know.
In order to be compatible withe the future v3.3, you have to add this line in "PluginInterface.h" file
extern "C" __declspec(dllexport) void messageProc(UINT Message, WPARAM wParam, LPARAM lParam);
And define this function (just give an empty dfinition for the moment) in your sourc file.
You can download demo project NppInsertPlugin here :
http://notepad-plus.sourceforge.net/commun/misc/NppInsertPlugin.zip
You will need also the newest version of Notepad++ binary to test :
http://notepad-plus.sourceforge.net/commun/misc/npp.v3.3NoOfficial.zip
Don
> So: a notification when file changes mode,
Considering the performance issue, there's few chance that I'll make it available, but I'll think about it.
> and a way of asking what mode the file is in would be great :-)
You can get the current view from notepad++ handle, the send the current scintilla view the message to get knowledge if read only mode is enabled.
See :
http://notepad-plus.sourceforge.net/uk/plugins-HOWTO.php
Don
>> So: a notification when file changes mode,
>Considering the performance issue, there's few chance that I'll make it available, but I'll think about it.
Hmm, yes, thinking of it, perhaps not all plugins are interested in all notifications.
Have you thought of a publish/subscribe system? Ie n++ publishes a lot of events,
and if a certain plugin want the event, it has to subscribe to it, by sending a subscribe message.
The current ones could be 'auto-subscribed' in order not to break current plugins?
Anyway, I got your answer, and won't be nagging you about this again
>> and a way of asking what mode the file is in would be great :-)
>You can get the current view from notepad++ handle,
> the send the current scintilla view the message to get knowledge if read only mode is enabled.
>See :
>http://notepad-plus.sourceforge.net/uk/plugins-HOWTO.php
Could you please elaborate a little bit on this?
I see NPPM_SETMENUITEMCHECK, which sets/unsets check on menu, but I don't see
NPPM_GETMENUITEMCHECK which would be perfect.
I see NPPM_GETMENUHANDLE, but it gives me the Plugins menu handle, insted of Edit menu
I do not see how I'd go about to ask a menuitem for its checked status.
Thanks for the answers
/Björn
This function needs to return a value, just like the equivalent windows function. At this time you may have no use for a return value so just tell everyone to always return the same value. Then later when we think of something we can do with a return value it will be there ready for use and won't require another interface change.
I also wonder why this is needed. Subclassing can do everything this can do, and a lot more.
> This function needs to return a value, just like the equivalent windows function.
Then it'll return LRESULT.
> I also wonder why this is needed. Subclassing can do everything this can do, and a lot more.
My intention is make easier the life of plugin authors, so they don't need to subclass Notepad++ handle.
OTOH, it can avoid to browser in the Notepad++ source code to see what it does. In long term, I will make Notepad++ messages and relative doc available for the plugin development.
Don
Hi donho, i'm bumping this old thread since i'm developing a new HTML plugin (another one :) ) that will do tag matching, tag inserting, and whatever else will come to my mind.
Are you still accepting requests for adding new messages to the plugin callback, or should i start thinking of subclassing? Anyway, the message i would need is WM_COMMAND, to handle a popup menu.
Thank you,
FC
> Are you still accepting requests for adding new messages to the plugin callback, or should i start thinking of subclassing?
The plugin system maintenance is always available. The subclassing is not encouraged. It should be used if there's no other solution.
> Anyway, the message i would need is WM_COMMAND, to handle a popup menu.
I can add this message, but I wonder if it's really useful for your use.
Could you give me more detail for "to handle a popup menu" point?
Don
You're right! I want to display a popupmenu through a function of my plugin, to show all tags available for insertion, and i was thinking to handle the result from that menu through the message queue.
But there's the TPM_RETURNCMD flag, that makes the TrackPopUpMenu function return what i need in a very simple way.
Thank you for bringing me on the right way.
Hmm, so is it appropriate to ask for another message/notification in this thread?
I'd _really_ like to know when the user changes a file from read/only to read/write
and vice versa. I finally found out a workaround to change the file state via
calling menu_handling functions. But that only toggles read/write - read/only.
I have no way of knowing what I am toggling _to_, unless I keep state of each open file.
So: a notification when file changes mode, and a way of asking what mode the file is in
would be great :-)
/Björn