Search in target is sometimes failing

Peter Goddard

I don’t know the difference between main and second scintilla. Could you tell me?

Ekopalypse

Open a clean npp without any files.
Create a new tab so that you have new_1 and new_2
Now right click on the tab and do move to other view for one of the tabs.
Result: one buffer can be accessed by nppData._scintillaMainHandle and the other by nppData._scintillaSecondHandle.

Peter Goddard

@Ekopalypse

I see what you mean, so a tab is only second scintilla if it’s in the other view? I have only tried my plugin on tabs that are in the regular view, so I would assume all my text is in the main scintilla. Thanks for explaining that, but I don’t think that’s the problem

Ekopalypse

@Peter-Goddard

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.

The only other suggestion I can make is that you try to find a
pattern when it returns -1 where it should return something else.

Peter Goddard

@Ekopalypse

This is what I have been trying to do. Usually, I have to wait a bit for it to work, or when I reopen notepad it starts to work again, or when I go to a different piece of text and then come back to it, it works. The lack of consistency has made it hard to try and figure this out. Thanks for the help anyways, I appreciate it

Ekopalypse

@Peter-Goddard

We don’t talk about casing problem,
I mean you are searching for “xml version” and expect to find
“XML version”, do we?

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?