if this area can be rectified, or at least provide an alternate non-locked down area, that would be great
They tried a compromise-solution like you suggested in the 7.6.0-7.6.2-era, but that was abandoned: there were too many people from IT departments who complained because with the alternate location, they couldn’t prevent employees from installing unapproved plugins. Everyone has different goals, and sometimes those goals are mutually exclusive.
If you already have IT permission for Notepad++ (since it’s in the locked-down Program FIles* area), maybe you could ask them to unlock the program files\Notepad++ hierarchy, or at least program files\notepad++\plugins hierarchy, so that you could install Notepad++ plugins without giving you full access to install other programs. If you couch it that way, and emphasize that it will make IT’s job easier so you won’t be pestering them every time you find a new plugin that you need, you might be able to convince them to do it.
As another potential alternative for you: you could use a portable version of Notepad++ (download the ZIP or 7ZIP instead of the installer), you can place your Notepad++ in some other folder hierarchy where you do have write permission; that way, you can install your own plugins without IT intervention – as long as your workplace policies won’t get you fired for trying to circumvent their restrictions. You can then make your file associations use the “portable” Notepad++. (That’s how I use Notepad++.)
it’s not exactly what you want, but Search > Incremental Search is the feature meant to mimic the browser-style previous/next/count dialog:
It gives the text and the number of matches, but doesn’t tell you how far through. However, the Status Bar just below the Incremental Search bar will give you an indication of where you are in the document.
Other than that, we have a FAQ on how to request new features – you could request that the current match-number be added next to the number of matches in the Incremental Search bar.
To ease migration, I sought out the same vintage version of the JEDI component libraries that Damjan used, but there was no getting a modern IDE to compile such old versions of the Borland sockets library or VirtualTreeView, so I linked in newer ones, at the risk of some undefined behaviour. I’ve already noticed a problem with tooltips leaving artifacts on the screen.
A new JVCL installation means nuking the previous one, or else installing a second IDE first. That can wait until the more critical bugs have been worked out.
@peterjones There’s no need for an apology, you’ve been a great deal of help in learning Notepad++ development. I truly appreciate all of the demonstrations you’ve provided and they were very helpful. I would advise you not to take a break from this forum, you’ve helped a lot and I am sure there are others that could use your assistance. I can be a bit hard headed at times which can lead to frustration and I am sorry for that. Have a great one! : - )
@alan-kilborn You’re exactly correct, this has been a great learning experience for me regarding Notepad++ plugin development. I plan to continue improving my current plugins and write new ones. Once again thank you @Alan-Kilborn and @PeterJones for pointing me in the right direction, you’ve been helped a great deal! : - )
Do we know of any workarounds in order to get good data?
Yes, like I showed above, editor.docLineFromVisible(editor.getFirstVisibleLine()), gives the actual document line number as derived from the display line number. Hence, the correct 75 that got printed on the second line in the final example box.
As implied in the editor section of the PythonScript docs when searching for “display line”, the visible line’s number is influenced by hidden lines and line wrapping. The “document line” is the real underlying line number for the line in the file. So there are a few conversion helpers: visibleFromDocLine converts the “document line” into the “display line”; docLineFromVisible converts the “display line” into “document line”; and wrapCount gives the number of “display lines” necessary to render the given “document line”. (All the other mentions of “display line” have to do with where HOME and END and their related commands end up.)
Similarly, if you want to set the first visible line (to scroll) based on an actual document line number, it would be editor.setFirstVisibleLine(editor.visibleFromDocLine(actualLineNumber))