Thread search problem can be solved by encoding detection?

[ollydbg]

Hi, all , In the current trunk version of CB, I still meet very annoying problem. see the image below:


By ollydbg at 2009-07-15

This problem is very annoying and can't be solved yet. The only workaround is like this:

Concerning ThreadSearch limitation, I already saw it but I didn't find any good solution to solve it.
If that's annoying for you, you can hide the controls panel and use the the ThreadSearch toolbar that is very small.
The check box to uncheck in settings dialog is "Show search widgets in ThreadSearch Messages panel".

Dje

In this post:
http://forums.codeblocks.org/index.php/topic,9873.msg69238.html#msg69238

I think the related code is in

Code

TextFileSearcher::eFileSearcherReturn TextFileSearcher::FindInFile(const wxString& filePath, wxArrayString &foundLines)
{
    eFileSearcherReturn success=idStringNotFound;
    wxString line;

    // Tests file existence
    if ( !wxFileName::FileExists(filePath) )
    {
        // We skip missing files without alerting user.
        // If a file has disappeared, it is not our problem.
        // cbMessageBox( filePath + _T(" does not exist."), _T("Error"), wxICON_ERROR);
        return idFileNotFound;
    }

    // File open
    if ( !m_TextFile.Open(filePath, wxConvFile) )
    {
        return idFileOpenError;
    }

    // Tests all file lines
    for ( size_t i = 0; i < m_TextFile.GetLineCount(); ++i )
    {
        line = m_TextFile.GetLine(i);
        if ( MatchLine(line) )
        {
            success=idStringFound;
            // An interesting line is found. We clean and add it to the provided array
            line.Replace(_T("\t"), _T(" "));
            line.Replace(_T("\r"), _T(" "));
            line.Replace(_T("\n"), _T(" "));
            line.Trim(false);
            line.Trim(true);

            foundLines.Add(wxString::Format(wxT("%d"), i + 1));
            foundLines.Add(line);
        }
    }

    // File close
    m_TextFile.Close();

    return success;
}

My question is:
Can we use the new encoding detection method(in the current trunk) to support threadsearch plugin?

Thanks!

[dje]

Hi ollydbg,

What encoding do you use ?
There is also an option to hide error pop ups in the options panel.

Dje

[Jenna]

My question is:
Can we use the new encoding detection method(in the current trunk) to support threadsearch plugin?

Can you try the attached patch ?

Just a quick hack to use encoding-detection.

Please tell me if it changes anything ?

By the way, I can search in textes detected as cp936 (chinese simplified) for example, without problems, as long as I do not search for chinese chararcters, but files can be opened, chars are just not found

Just tested when using encoding detection: the chars are found, only the preview is incorrect, but that should not be a problem to change.

EDIT:

updated the patch: preview now also works with the cp936 text.

Forgoet to write:
you have to add the mozilla_chardet directory below C::B's include directory to the compiler's search-path.

[attachment deleted by admin]

[ollydbg]

Can you try the attached patch ?

Just a quick hack to use encoding-detection.

Please tell me if it changes anything ?

thanks

I have applied in my local working copy, and it seems the bug was solved.

ThreadSearch can open all the files now! (No "Failed to open XXXX" messagebox any more)

Really great!!!

[killerbot]

will this be applied to trunk then ? Jens ?

[Jenna]

will this be applied to trunk then ? Jens ?

Totally forgot that, thanks for reminding.
I'm currently testing the needed changes to automake-system, and will test it on windows, if all is okay, I will commit the patch.

[Jenna]

Applied to cc-branch (r5711) and trunk (r5712).