Search in target is sometimes failing

Michael Vincent

@Ekopalypse said in Search in target is sometimes failing:

only second scintilla

Not strictly true, if you have two views open and you close the
main view the second view stays to be the second.

I second @Ekopalypse. In my plugins, I use:

HWND getCurScintilla()
{
    int which = -1;
    ::SendMessage( nppData._nppHandle, NPPM_GETCURRENTSCINTILLA, 0,
                   ( LPARAM )&which );
    return ( which == 0 ) ? nppData._scintillaMainHandle :
           nppData._scintillaSecondHandle;
}

[,...]

int start = (int)::SendMessage( getCurScintilla(), SCI_GETSELECTIONSTART, 0, 0 );

This way, I can dynamically get the currently selected Scintilla view (1 or 2).

As for your code, it works for me with following NppExec mock-up:

SCI_SENDMSG SCI_TARGETWHOLEDOCUMENT

SCI_SENDMSG SCI_GETSELECTIONSTART
SET LOCAL START = $(MSG_RESULT)
SCI_SENDMSG SCI_GETSELECTIONEND
SET LOCAL END = $(MSG_RESULT)
SCI_SENDMSG SCI_SETTARGETRANGE $(START) $(END)

SCI_SENDMSG SCI_SEARCHINTARGET 11 "xml version"
ECHO START=$(START) END=$(END) ==> $(MSG_RESULT)

Running that NppExec script on the following file with NO highlighted text:

hello there
xml version
goodbye there

returns:
START=38 END=38 ==> -1

and if I highlight the whole document, it returns:
START=0 END=38 ==> 12

I think you may be able to simplify and not bother getting the start, end and SETTARGETRANGE and instead just use a call to SCI_TARGETFROMSELECTION

Cheers.

Michael Vincent

@Peter-Goddard said in Search in target is sometimes failing:

That could be it, but why would it be only working sometimes?

Your search string is ANSI (const char *) but your file is Unicode?

Ekopalypse

@Peter-Goddard

As said earlier, npp does also use SearchInTarget therefore it could be
that npp sets flags which aren’t useful in your case.
For example, having a flag SCFIND_WHOLEWORD might conflict with
your “xml version”.

Peter Goddard

@Michael-Vincent

I will try and use SCI_TARGETFROMSELECTION. I am not sure what you mean by, “Your search string is ANSI (const char *) but your file is Unicode?”. I am very new to this all, so thanks for the help

Ekopalypse

@Peter-Goddard said in Search in target is sometimes failing:

I am not sure what you mean by, “Your search string is ANSI (const char *) but your file is Unicode?”

this is actually a very advanced topic and MUST be understood by
every programmer which handles text.
I suggest reading this and you have to understand, that Windows API,
internally, handles everything with UTF16 and that a char pointer is start of your nightmares. :-)

Peter Goddard

@Ekopalypse
Okay, thanks, as I said, I have limited experience with any of this stuff. I have only just started to program and I really appreciate you helping me out.

Ekopalypse

@Peter-Goddard

Every big journey starts with a first step but you only reach your
destination if you keep walking. ;-)

Peter Goddard

@Michael-Vincent

After testing, SCI_TARGETFROMSELECTION, I think you may have been right. This seems to have fixed it

Michael Vincent

@Peter-Goddard said in Search in target is sometimes failing:

Okay, thanks, as I said, I have limited experience with any of this stuff. I have only just started to program and I really appreciate you helping me out.

I understand, I’m not a programmer but have muddled my way through Scintilla docs and other N++ plugins and been able to hack together some working code.

@Ekopalypse has it right about Unicode / ANSI. By default, all N++ plugins are compiled for Unicode as N++ no longer published an ANSI version. So the difference in your plugin when handling text in N++ documents (like searching for it) is to expect Unicode.

You’ll probably see character strings in N++ plugins initialized with:

TCHAR cString[MAX_PATH];

since this can be ANSI or Unicode depending on compiler switches and that was needed back when there was an ANSI N++.

https://docs.microsoft.com/en-us/office/client-developer/outlook/mapi/tchar

Cheers.

Ekopalypse

@Peter-Goddard

By the way, you defined your start and end being ints.
But SendMessage returns an LRESULT which is defined as LONG_PTR, so just be careful because a position might overflow it.

Peter Goddard

@Ekopalypse So how would I prevent it from overflowing?

Ekopalypse

@Peter-Goddard said in Search in target is sometimes failing:

So how would I prevent it from overflowing?

Not sure I understand this question because I guess you know the obvious answer,
which would be “use a datatype which is big enough to hold the values”, yourself.

Peter Goddard

@Ekopalypse As I said, I am very new at this so I thought I would just make sure I am understanding you correctly. I am assuming I use LONG_PTR instead of int, correct?

Ekopalypse

@Peter-Goddard

There are several possible data types that can be used, but without knowing your code and concept, it is hard to say what to use.
Personally, I would use INT_PTR, but if your result is ever converted to long, I would probably use LONG_PTR.

Peter Goddard

@Ekopalypse Would you mind looking at my code for one part of my plugin that is failing?

Ekopalypse

@Peter-Goddard

Sorry, but there is a small, but unfortunately insurmountable problem,
I cannot program in C++, I am a python junkie :-)

Peter Goddard

@Ekopalypse No problem. Maybe you could just confirm that this is a memory issue for me? After restarting notepad my plugin seems to work and I can use it over and over again until it fails and then won’t work until I restart notepad. I’m pretty sure this means it’s a memory problem, and I don’t really know where to go from here

Ekopalypse

@Peter-Goddard

until it fails and then won’t work until I restart notepad

yes, that could mean that you have an overflow.
There are several ways to find out what is causing it.
Old school, use print statements in your code and check certain parameters.
More modern, use Visual Studios features like Analyzer and Debugger to see what is going on.
I assume you are using Visual Studio for development,
there is one setting I would suggest to activate, it is to treat every warning as an error.
(Project->Properties->Configuration Properties->C/C+±>General->Treat warnings as errors->Yes)

Peter Goddard

@Ekopalypse

Thanks, I’ll try that.

There is another thing I have noticed and I wonder if you could help me with it. The text file I am working on is around 40’000 lines long, and as I said before I am formatting small parts of that file and eventually it will start to mess up. What I have noticed though, is that when I copy and paste a part of the original text file to a separate notepad tab and try to format it, then once it’s formatted it, delete it and then repeat the process, the formatting process never messes up. Could it be that the length of the text file has something to do with how many times I can use my plugin on it?

Ekopalypse

@Peter-Goddard

yes, could be but to me it sounds more like an issue with the “new” content.
For example, let’s say we have a text like this

This is a sampl of a text which has two wrong words named sampl.

Now let’s assume your plugin is used to auto correct wrong words.
If your code logic would be

find all instances of the wrong word
Loop over the results and replace with the correct word

then it would fail as you invalidate the position of the second sampl
word by replacing the first one.
In such a scenario replacing from bottom to top would avoid this.
Of course, there are multiple other ways to solve this issue as well.