I try to make a plugin that implements a home made
locking mechanism for certain opened files.
basically I want to put a file 'filename'.lockfile into
the file's directory when it is opened. However, if there already
exists a lockfile I want to open the file in read only mode.
There are legacy reasons for this...
Questions:
1 - Can I tell npp to open a file readonly? If so, how?
I cannot see anything obvious in the plugin interface.
2 - I managed to get a plugin working to write the filename of files I
open and close, to a debug file. I catch, in beNotified, the events
NPPN_FILEBEFORECLOSE
NPPN_FILEOPENED
NPPN_FILECLOSED
NPPN_FILEBEFOREOPEN
and ask for the filename.
But the log suggets that FILEOPENED arrives before FILEBEFOREOPEN
and FILECLOSED arrives before FILEBEFORECLOSE.
Does this happen in c/c++ plugins as well, or am I to look
for realtime phenomenas?
Values used, from Notepad_plus_msgs.h
NPPN_FIRST : constant Unsigned := 1000;
NPPN_READY : constant Unsigned := NPPN_FIRST + 1 ;
-- To notify plugins that all the procedures of launchment of notepad++ are done.
NPPN_TBMODIFICATION : constant Unsigned := NPPN_FIRST + 2 ;
-- To notify plugins that toolbar icons can be registered
NPPN_FILEBEFORECLOSE : constant Unsigned := NPPN_FIRST + 3 ;
-- To notify plugins that the current file is about to be closed
NPPN_FILEOPENED : constant Unsigned := NPPN_FIRST + 4 ;
-- To notify plugins that the current file is just opened
NPPN_FILECLOSED : constant Unsigned := NPPN_FIRST + 5 ;
-- To notify plugins that the current file is just closed
NPPN_FILEBEFOREOPEN : constant Unsigned := NPPN_FIRST + 6 ;
-- To notify plugins that the current file is about to be opened
NPPN_FILEBEFORESAVE : constant Unsigned := NPPN_FIRST + 7 ;
-- To notify plugins that the current file is about to be saved
NPPN_FILESAVED : constant Unsigned := NPPN_FIRST + 8 ;
-- To notify plugins that the current file is just saved
NPPN_SHUTDOWN : constant Unsigned := NPPN_FIRST + 9 ;
-- To notify plugins that Notepad++ is about to be shutdowned.
I'm using npp 4.8.2 for this test.
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to clearify, I get the following messages when openeing and closing npp.
it loads 3 files from last session,
config.xml, langs.xml and doLocalConf.xml
Each plugin function called, writes its name, and sometimes some of its arguments
it was called with.
beNotified also calls SendMessage as
Result := Win32.Winuser.SendMessage(
hWnd => Global_Npp_Data.nppHandle,
Msg => NPPM_GETFULLCURRENTPATH,
wParam => Path_Buffer'length,
lParam => Win32_Style_C_Path_Pointer);
and prints the result along with the values pointed by Win32_Style_C_Path_Pointer
Interesting to see is
- where is the call for 'new 1' FILEOPENED?
- where is the call for doLocalConf.xml FILEBEFOREOPEN?
- where is the call for doLocalConf.xml FILECLOSED?
Why is 'new 1' and 'new 2' referencead at all?
'new 1' perhaps npp does not know that is should load
last session at that moment, I guess, but 'new 2'?
It seems, in Notepad_Plus.cpp, that
NPPM_GETFULLCURRENTPATH relies on
char *fileStr = strcpy(str, _pEditView->getCurrentTitle())
to find out current file.
But _pEditView is not updated when NPPN_FILEBEFOREOPEN notification is fired,
thus giving the filename of the file that, technically still is current, but not for many
more milliseconds. When NPPN_FILEOPENED is fired, _pEditView is updated, and the newly opened file is returned.
Is there any chance of changing/fixing this? I mean, it seems useless to call
NPPM_GETFULLCURRENTPATH in a NPPN_FILEBEFOREOPEN event, when the info is useless.
Perhaps a new field in _pEditView, like pendingOpeningFile? The
file to be opened is known when the event is fired.
Then a NPPM_GETFULLCURRENTPATHOFFILETOBEOPENED telegram could be defined,
to look at
char *fileStr = strcpy(str, _pEditView->getPendingOpeningFile())
instead
Or is there another better way of getting the name of a file that is about to be opened?
And is there a way of opening it readonly?
I see some reopening procedures, but can I send some messages from a plugin to n++, and
make it reopen a file in readonly mode?
Comments anyone?
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> _pEditView is not updated when NPPN_FILEBEFOREOPEN notification is fired,
> thus giving the filename of the file that, technically still is current, but not for many
> more milliseconds. When NPPN_FILEOPENED is fired, _pEditView is updated, and the newly opened file is returned.
_pEditView is a pointer to point to the current view (mainScintillaView or subScintillaView). It won't be updated during the file opening operation since the file will be opened in the current view.
I don't see then what I can fix.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, thinking of it,
it seems like I could do with just a
way to change an open file to readonly.
I could trap the NPPM_FILEOPENED event, determine if I need to
change the mode/reopen as readonly or not.
My original intent was to catch the NPPM_BEFOREFILEOPEN to determin if I need
the readonly or not. But I guess I could bypass that.
So, that leaves me with 2 questions.
1 - can I change the mode to readonly, on an open file (Say by sending a message)? How, then?
2 - would it be of any interest to share my plugin, as a sample of how
to write plugins in Ada?
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, thanks I found it.
but as I state in
<http://sourceforge.net/forum/message.php?msg_id=4959327>
the drawback of using menucommand for this is that it _toggles_ the readwrite/readonly status.
This means I need to keep state myself of the file's status, because I can't find out the mode myself.
But Ok, I do that now, in a test plugin.
However, when the user changes the mode, by using the menu command, I get lost.
Therefore, I'd _really_ like a notification of when the current file is changing ro/rw mode.
My intention is this.
We are 50+ developers, that sometime in the future will use subversion or some version handling system.
However, due to rollout/education/company policys/whatever we still use emacs (non-color) on unix, with a
home-brewed file-locking system from early 1980's.
I'd really like them to migrate to n++ and samba. (Fileshare unix for windows)
I have a prototype, that creates a lock-file when the user opens a file that is not associated with a lock-file.
If there already is a lock-file present, the file is opened in r/o-mode, using the menu command message.
But most people just read the files, instead of changing them. Common in legacy systems with lots of code.
So, the best thing for me/us would be to always open a file in r/o mode (my plugin fixes that,
by sending the menu command on NPPM_FILEOPENED)
and get notified when the user uses the menu to set it in r/w mode.
Then I could create the lock-file, or if present already, bounce back to r/o mode, with a message to the user.
But it needs a notification message, when the user changes the file mode.
I would not like to hack it myself, and have it refused by mainstream n++.
But if I add the notification myself, and send a patch, would it be considered in the mainstream n++?
(If yes, where do I send the patch?)
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, yes, but a fix/new message would be a nicer solution.
Would that be received with joy, or is that of no interest?
What I mean is, a change is needed i npp itself, and
if I hack npp, I need to bring that hack along each new
version. So I'd like it to be incorporated into the main development branch.
How would I go about to contribute?
/Björn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi again list!
I try to make a plugin that implements a home made
locking mechanism for certain opened files.
basically I want to put a file 'filename'.lockfile into
the file's directory when it is opened. However, if there already
exists a lockfile I want to open the file in read only mode.
There are legacy reasons for this...
Questions:
1 - Can I tell npp to open a file readonly? If so, how?
I cannot see anything obvious in the plugin interface.
2 - I managed to get a plugin working to write the filename of files I
open and close, to a debug file. I catch, in beNotified, the events
NPPN_FILEBEFORECLOSE
NPPN_FILEOPENED
NPPN_FILECLOSED
NPPN_FILEBEFOREOPEN
and ask for the filename.
But the log suggets that FILEOPENED arrives before FILEBEFOREOPEN
and FILECLOSED arrives before FILEBEFORECLOSE.
Does this happen in c/c++ plugins as well, or am I to look
for realtime phenomenas?
Values used, from Notepad_plus_msgs.h
NPPN_FIRST : constant Unsigned := 1000;
NPPN_READY : constant Unsigned := NPPN_FIRST + 1 ;
-- To notify plugins that all the procedures of launchment of notepad++ are done.
NPPN_TBMODIFICATION : constant Unsigned := NPPN_FIRST + 2 ;
-- To notify plugins that toolbar icons can be registered
NPPN_FILEBEFORECLOSE : constant Unsigned := NPPN_FIRST + 3 ;
-- To notify plugins that the current file is about to be closed
NPPN_FILEOPENED : constant Unsigned := NPPN_FIRST + 4 ;
-- To notify plugins that the current file is just opened
NPPN_FILECLOSED : constant Unsigned := NPPN_FIRST + 5 ;
-- To notify plugins that the current file is just closed
NPPN_FILEBEFOREOPEN : constant Unsigned := NPPN_FIRST + 6 ;
-- To notify plugins that the current file is about to be opened
NPPN_FILEBEFORESAVE : constant Unsigned := NPPN_FIRST + 7 ;
-- To notify plugins that the current file is about to be saved
NPPN_FILESAVED : constant Unsigned := NPPN_FIRST + 8 ;
-- To notify plugins that the current file is just saved
NPPN_SHUTDOWN : constant Unsigned := NPPN_FIRST + 9 ;
-- To notify plugins that Notepad++ is about to be shutdowned.
I'm using npp 4.8.2 for this test.
/Björn
Just to clearify, I get the following messages when openeing and closing npp.
it loads 3 files from last session,
config.xml, langs.xml and doLocalConf.xml
Each plugin function called, writes its name, and sometimes some of its arguments
it was called with.
beNotified also calls SendMessage as
Result := Win32.Winuser.SendMessage(
hWnd => Global_Npp_Data.nppHandle,
Msg => NPPM_GETFULLCURRENTPATH,
wParam => Path_Buffer'length,
lParam => Win32_Style_C_Path_Pointer);
and prints the result along with the values pointed by Win32_Style_C_Path_Pointer
Interesting to see is
- where is the call for 'new 1' FILEOPENED?
- where is the call for doLocalConf.xml FILEBEFOREOPEN?
- where is the call for doLocalConf.xml FILECLOSED?
Why is 'new 1' and 'new 2' referencead at all?
'new 1' perhaps npp does not know that is should load
last session at that moment, I guess, but 'new 2'?
------From log-------
getFuncsArray
setInfo
setInfo - nppHandle is set
setInfo - scintillaMainHandle is set
setInfo - scintillaSecondHandle is set
setInfo done
getName
messageProc - p1,p2 -> 3, 0
beNotified - NPPN_TBMODIFICATION
messageProc - p1,p2 -> 1, 0
messageProc - p1,p2 -> 36, 0
messageProc - p1,p2 -> 3, 0
messageProc - p1,p2 -> 5, 0
beNotified - NPPN_FILEBEFOREOPEN start
beNotified - Result : 1
beNotified - Path_Pointer:'new 1'
beNotified - NPPN_FILEBEFOREOPEN stop
beNotified - NPPN_FILEOPENED start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\config.xml'
beNotified - NPPN_FILEOPENED stop
beNotified - NPPN_FILEBEFOREOPEN start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\config.xml'
beNotified - NPPN_FILEBEFOREOPEN stop
beNotified - NPPN_FILEOPENED start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\langs.xml'
beNotified - NPPN_FILEOPENED stop
beNotified - NPPN_FILEBEFOREOPEN start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\langs.xml'
beNotified - NPPN_FILEBEFOREOPEN stop
beNotified - NPPN_FILEOPENED start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\doLocalConf.xml'
beNotified - NPPN_FILEOPENED stop
beNotified - NPPN_READY
messageProc - p1,p2 -> 36, 0
messageProc - p1,p2 -> 36, 0
messageProc - p1,p2 -> 3, 0
messageProc - p1,p2 -> 5, 2
messageProc - p1,p2 -> 28, 0
beNotified - NPPN_FILEBEFORECLOSE start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\doLocalConf.xml'
beNotified - NPPN_FILEBEFORECLOSE stop
messageProc - p1,p2 -> 5, 0
beNotified - NPPN_FILECLOSED start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\langs.xml'
beNotified - NPPN_FILECLOSED stop
beNotified - NPPN_FILEBEFORECLOSE start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\langs.xml'
beNotified - NPPN_FILEBEFORECLOSE stop
messageProc - p1,p2 -> 5, 0
beNotified - NPPN_FILECLOSED start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\config.xml'
beNotified - NPPN_FILECLOSED stop
beNotified - NPPN_FILEBEFORECLOSE start
beNotified - Result : 1
beNotified - Path_Pointer:'D:\npp_source\PowerEditor\visual.net\Debug\config.xml'
beNotified - NPPN_FILEBEFORECLOSE stop
messageProc - p1,p2 -> 5, 0
messageProc - p1,p2 -> 5, 0
beNotified - NPPN_FILECLOSED start
beNotified - Result : 1
beNotified - Path_Pointer:'new 2'
beNotified - NPPN_FILECLOSED stop
beNotified - NPPN_SHUTDOWN
messageProc - p1,p2 -> 28, 0
------log end -----------
/Björn
Answering my own posts, since noone else does...
It seems, in Notepad_Plus.cpp, that
NPPM_GETFULLCURRENTPATH relies on
char *fileStr = strcpy(str, _pEditView->getCurrentTitle())
to find out current file.
But _pEditView is not updated when NPPN_FILEBEFOREOPEN notification is fired,
thus giving the filename of the file that, technically still is current, but not for many
more milliseconds. When NPPN_FILEOPENED is fired, _pEditView is updated, and the newly opened file is returned.
Is there any chance of changing/fixing this? I mean, it seems useless to call
NPPM_GETFULLCURRENTPATH in a NPPN_FILEBEFOREOPEN event, when the info is useless.
Perhaps a new field in _pEditView, like pendingOpeningFile? The
file to be opened is known when the event is fired.
Then a NPPM_GETFULLCURRENTPATHOFFILETOBEOPENED telegram could be defined,
to look at
char *fileStr = strcpy(str, _pEditView->getPendingOpeningFile())
instead
Or is there another better way of getting the name of a file that is about to be opened?
And is there a way of opening it readonly?
I see some reopening procedures, but can I send some messages from a plugin to n++, and
make it reopen a file in readonly mode?
Comments anyone?
/Björn
http://sourceforge.net/forum/message.php?msg_id=4622701
Perhaps you can wrap some own utility around that.
> _pEditView is not updated when NPPN_FILEBEFOREOPEN notification is fired,
> thus giving the filename of the file that, technically still is current, but not for many
> more milliseconds. When NPPN_FILEOPENED is fired, _pEditView is updated, and the newly opened file is returned.
_pEditView is a pointer to point to the current view (mainScintillaView or subScintillaView). It won't be updated during the file opening operation since the file will be opened in the current view.
I don't see then what I can fix.
Don
Perhaps _pEditView is not the place.
How about storing the filename to be opened is another, perhaps, global variable in
the Notepad_Plus.cpp file.
That, combined with another message like
NPPM_GETFULLCURRENTPATHOFFILETOBEOPENED telegram could be defined,
to return the value of that global varible
something like
1- open file
2- store filename in global var
3- notify file_beforeopen
4- update _pEditView
5- notify file_opened
By doing this, a message NPPM_GETFULLCURRENTPATHOFFILETOBEOPENED, sent between 3 and 4 above,
would get the name stored in 2.
Oh, and is it possible to, from a plugin, to ask an open file to be reopened in readonly-mode?
/Björn
Hmm, thinking of it,
it seems like I could do with just a
way to change an open file to readonly.
I could trap the NPPM_FILEOPENED event, determine if I need to
change the mode/reopen as readonly or not.
My original intent was to catch the NPPM_BEFOREFILEOPEN to determin if I need
the readonly or not. But I guess I could bypass that.
So, that leaves me with 2 questions.
1 - can I change the mode to readonly, on an open file (Say by sending a message)? How, then?
2 - would it be of any interest to share my plugin, as a sample of how
to write plugins in Ada?
/Björn
> 1 - can I change the mode to readonly, on an open file (Say by sending a message)? How, then?
use NPPM_MENUCOMMAND you can do all the commands, including to set current doc read only.
See :
http://notepad-plus.svn.sourceforge.net/viewvc/notepad-plus/PowerEditor/src/MISC/PluginsManager/Notepad_plus_msgs.h?revision=195&view=markup
For all available commands, see :
http://notepad-plus.svn.sourceforge.net/viewvc/notepad-plus/PowerEditor/src/menuCmdID.h?revision=200&view=markup
Don
yes, thanks I found it.
but as I state in
<http://sourceforge.net/forum/message.php?msg_id=4959327>
the drawback of using menucommand for this is that it _toggles_ the readwrite/readonly status.
This means I need to keep state myself of the file's status, because I can't find out the mode myself.
But Ok, I do that now, in a test plugin.
However, when the user changes the mode, by using the menu command, I get lost.
Therefore, I'd _really_ like a notification of when the current file is changing ro/rw mode.
My intention is this.
We are 50+ developers, that sometime in the future will use subversion or some version handling system.
However, due to rollout/education/company policys/whatever we still use emacs (non-color) on unix, with a
home-brewed file-locking system from early 1980's.
I'd really like them to migrate to n++ and samba. (Fileshare unix for windows)
I have a prototype, that creates a lock-file when the user opens a file that is not associated with a lock-file.
If there already is a lock-file present, the file is opened in r/o-mode, using the menu command message.
But most people just read the files, instead of changing them. Common in legacy systems with lots of code.
So, the best thing for me/us would be to always open a file in r/o mode (my plugin fixes that,
by sending the menu command on NPPM_FILEOPENED)
and get notified when the user uses the menu to set it in r/w mode.
Then I could create the lock-file, or if present already, bounce back to r/o mode, with a message to the user.
But it needs a notification message, when the user changes the file mode.
I would not like to hack it myself, and have it refused by mainstream n++.
But if I add the notification myself, and send a patch, would it be considered in the mainstream n++?
(If yes, where do I send the patch?)
/Björn
Hmm, yes, but a fix/new message would be a nicer solution.
Would that be received with joy, or is that of no interest?
What I mean is, a change is needed i npp itself, and
if I hack npp, I need to bring that hack along each new
version. So I'd like it to be incorporated into the main development branch.
How would I go about to contribute?
/Björn