Search in target is sometimes failing

[Peter Goddard]

@Ekopalypse

I tell it to search for, “xml version”, but specifically it should find,
in a text file that looks a bit like this

[Ekopalypse]

@Peter-Goddard

maybe you should, explicitly, set your searchFlags.

[Peter Goddard]

@Ekopalypse

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

[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