Could someone recommend a method of forcefully updating both the Main and Second views from an external lexer plugin that will also force Notepad++ to update the doc pointer to the non-active view, call for styling, and then revert back to the original pointer?
What's going on is that I'm using a normal style ( styleID < 32 ) that shows in the wordstyledlg to allow users to configure highlighters. This style info is then read by a highlighter init routine and sends the appropriate messages to scintilla to configure the indicators. In the dlg window the 'bold' translates to the highlighter being 'active', 'italics' translates to 'erase highlight on leading whitespace', and 'underline' to the indicator drawing over/under the text.
The part that obviously doesn't work correctly for the non-active view is the changing of whitespace highlighting because it requires a re-lexing of the doc, which is easy enough to call (with SCI_STARTSTYLING) on the active doc, as well as the non-active. BUT! When called on the non-active view, Notepad++ doesn't update the Scintilla pointer (I think that's SCI_SETDOCPOINTER), so when a call is done for something like SCI_BRACEMATCH you end up with no-matching brace.
I had thought about managing the doc pointer myself, but there's a problem there also. I'm not finding a way to use either Notepad++ or Scintilla messages to determine which views doc pointer is current without going through quite a few steps.
Perhaps, get the index for both views, test for the current view, set a flag, send the activate doc message for non-active, do styling, see the flag and revert to the previous index...
Is there a simple method to handle this that anyone can suggest?
Thanks,
almostatuomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So what is it exactly that you'd like to do? When the user is changing the style definitions using the dialog, both views (if necessary) have to be updated for it?
I believe a notification that the style has changed has been added recently, special for external lexers, maybe that is helpful?
Also, if you could manage to keep the style the same and just apply a indicator, it will transfer to both views and stick with the document throughout switches (use the modern type though).
Finally, using those checkboxes is kind of counter intuitive, I know why you do it but if it's more than a personal project, I would suggest expanding the plugin to add a few menu options to configure it (using a custom dialog if required). That way you immediately remove the problem of having to take control of the style dialog (which, is a bad thing to do imo)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...I believe a notification that the style has changed has been added recently, special for external lexers, maybe that is helpful?..."
Yep, that the WORDSTYLESUPDATED notification. No matter now, it is all figured out now. :D
As far as using menu items with checks, I'd like to, but I haven't looked around long enough at the menu system to see how multi-level cascading works. Also, setting up a second styles configuration for the indicators/highlighters doesn't seem like all that good of a solution. When the built-in highlighters are configured in the standard Styles Dialog.
Like I said though, the style updating and keyword lists are updating excellently now with focus returning the the WordStylDlg.
All is good.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I find it difficult to follow, so what im going to say might be totally irrelevant.
I know that the BufferID is sent each time a document is swapped. You can store it untill your document is put into view, I suppose you mean that when the new document is swapped in, oyu want your special styling to take place?
Anyway, its not a good idea to take over pointer management, it can easily break if something is changed internally, so your idea of taking another approach is a good one :] Although, doing a temporary document swap in a single function shouldnt be too harmful, but I wouldn't recommend it.
However, a plugin can trap Scintilla notification messages. Wouldnt it be possible to catch the styling one, or something else, check the lexer being used and then sending the styling messages if it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Darn, triggering off of the BUFFERACTIVATED doesn't seem to work correctly when ACTIVATEDOC is what activates the buffer. The notification arrives prior to Notepad++ doing the switchEditViewTo(whichView) and activateDoc(index)! So I guess _another_ handler is needed at the BUFFERACTIVATED handler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello plugin developers!
Could someone recommend a method of forcefully updating both the Main and Second views from an external lexer plugin that will also force Notepad++ to update the doc pointer to the non-active view, call for styling, and then revert back to the original pointer?
What's going on is that I'm using a normal style ( styleID < 32 ) that shows in the wordstyledlg to allow users to configure highlighters. This style info is then read by a highlighter init routine and sends the appropriate messages to scintilla to configure the indicators. In the dlg window the 'bold' translates to the highlighter being 'active', 'italics' translates to 'erase highlight on leading whitespace', and 'underline' to the indicator drawing over/under the text.
The part that obviously doesn't work correctly for the non-active view is the changing of whitespace highlighting because it requires a re-lexing of the doc, which is easy enough to call (with SCI_STARTSTYLING) on the active doc, as well as the non-active. BUT! When called on the non-active view, Notepad++ doesn't update the Scintilla pointer (I think that's SCI_SETDOCPOINTER), so when a call is done for something like SCI_BRACEMATCH you end up with no-matching brace.
I had thought about managing the doc pointer myself, but there's a problem there also. I'm not finding a way to use either Notepad++ or Scintilla messages to determine which views doc pointer is current without going through quite a few steps.
Perhaps, get the index for both views, test for the current view, set a flag, send the activate doc message for non-active, do styling, see the flag and revert to the previous index...
Is there a simple method to handle this that anyone can suggest?
Thanks,
almostatuomated
So what is it exactly that you'd like to do? When the user is changing the style definitions using the dialog, both views (if necessary) have to be updated for it?
I believe a notification that the style has changed has been added recently, special for external lexers, maybe that is helpful?
Also, if you could manage to keep the style the same and just apply a indicator, it will transfer to both views and stick with the document throughout switches (use the modern type though).
Finally, using those checkboxes is kind of counter intuitive, I know why you do it but if it's more than a personal project, I would suggest expanding the plugin to add a few menu options to configure it (using a custom dialog if required). That way you immediately remove the problem of having to take control of the style dialog (which, is a bad thing to do imo)
"...I believe a notification that the style has changed has been added recently, special for external lexers, maybe that is helpful?..."
Yep, that the WORDSTYLESUPDATED notification. No matter now, it is all figured out now. :D
As far as using menu items with checks, I'd like to, but I haven't looked around long enough at the menu system to see how multi-level cascading works. Also, setting up a second styles configuration for the indicators/highlighters doesn't seem like all that good of a solution. When the built-in highlighters are configured in the standard Styles Dialog.
Like I said though, the style updating and keyword lists are updating excellently now with focus returning the the WordStylDlg.
All is good.
I find it difficult to follow, so what im going to say might be totally irrelevant.
I know that the BufferID is sent each time a document is swapped. You can store it untill your document is put into view, I suppose you mean that when the new document is swapped in, oyu want your special styling to take place?
Anyway, its not a good idea to take over pointer management, it can easily break if something is changed internally, so your idea of taking another approach is a good one :] Although, doing a temporary document swap in a single function shouldnt be too harmful, but I wouldn't recommend it.
However, a plugin can trap Scintilla notification messages. Wouldnt it be possible to catch the styling one, or something else, check the lexer being used and then sending the styling messages if it?
ooooohhhhh; so much closer!
Once you realize that the index returned from NPPM_GETCURRENTDOCINDEX is not the same as the index needed for NPPM_ACTIVATEDOC things go smoother.
Now I just need to ensure that focus actually goes back to the WordStyleDlg.
Any ideas on that?
Thanks for the reply harrybharry, it was relevant.
Actually it even led to a little bit of a inspiration to retry something I had shot down yesterday. :D
I'll try out a couple things and post again with the results in a bit.
Darn, triggering off of the BUFFERACTIVATED doesn't seem to work correctly when ACTIVATEDOC is what activates the buffer. The notification arrives prior to Notepad++ doing the switchEditViewTo(whichView) and activateDoc(index)! So I guess _another_ handler is needed at the BUFFERACTIVATED handler.