Search in target is sometimes failing
-
@Ekopalypse, I meant that the function fails to find the text I am looking for, so it returns -1. Also, what do you mean by thread?
-
what do you mean by thread?
Do you create a thread within your plugin which is doing the search?
If so, this is not safe as npp itself does a lot of SETTARGETRANGE,
which means that your plugin code SCI_SEARCHINTARGET could
be searching on unknown territory. -
Do you mean like this?
My main plugin function is “Parse and Format Log File”, and I use “Test123” to help me test some of the code I’m writing and, “FindIt” is the function that I posted above.
Sorry, I’m really new at this, so I don’t know what you mean completely.
-
No, I mean this.
So because you don’t know about threads we assume you
are not using it. Then I would assume that the text to be
searched is not in the main scintilla but in the second, could this be? -
I don’t know the difference between main and second scintilla. Could you tell me?
-
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. -
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
-
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. -
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
-
We don’t talk about casing problem,
I mean you are searching for “xml version” and expect to find
“XML version”, do we? -
I tell it to search for, “xml version”, but specifically it should find,
in a text file that looks a bit like this
-
maybe you should, explicitly, set your searchFlags.
-
That could be it, but why would it be only working sometimes?
-
@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 ==> -1and if I highlight the whole document, it returns:
START=0 END=38 ==> 12I 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.
-
@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?
-
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”. -
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
-
@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. :-) -
@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. -
Every big journey starts with a first step but you only reach your
destination if you keep walking. ;-)