Search in target is sometimes failing
-
Hello, I am making my own plugin and a part of this plugin involves searching for, “xml version” in a selected area of text. I am using SCI_GETSELECTIONSTART and SCI_GETSELECTIONEND to retrieve the starting and endpoints of the selection and then setting the start and endpoints of the search with SCI_SETTARGETRANGE. Then I am using SCI_SEARCHTARGET to find “xml version” in the selected text. This is where my problem arises as sometimes this function fails and returns -1 and sometimes it works.
This is the function I made to do what I described above.
I am not sure where I am going wrong, and if anyone could provide any help, that would be great.
Thanks
-
I’m not sure about your definition of “sometimes this function fails and returns -1”
because -1 is the return value if the text to be searched for is not found.
But if you are sure that the text should have been found I assume
you are using a thread, could that be? -
@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 therereturns:
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. :-)
