https://bugs.documentfoundation.org/show_bug.cgi?id=94557

Lionel Elie Mamane <lio...@mamane.lu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |caol...@redhat.com

--- Comment #7 from Lionel Elie Mamane <lio...@mamane.lu> ---
(In reply to Julien Nabet from comment #5)
> Robert/Lionel: I can try to search where is managed combobox within a grid
> control but I'd like to be sure that we want it to be case sensitive. Any
> thoughts?

<sigh> Somebody entering a value in the list certainly expects that it is found
case-insensitively. OTOH, I understand the concern of the reporter of bug
67990, that he also wants to be able to force two different values with
differing case.

I think of this bug and bug 67990, this one is the worst one, and the immediate
action should be to revert your previous commit. If we can fix bug 67990 in a
way that does not reintroduce this one (I'm not sure how yet), then by all
means, that's even better.

commit 76f33f10309b0ee384a75a7a854858b068d60495
Author: Julien Nabet <serval2...@yahoo.fr>
Date:   Mon Mar 16 22:31:23 2015 +0100

    tdf#67990: Management of case in combobox


    1) Combobox were used with autocomplete with default (false) value for
matchCase
    => so initialize autocomplete with true value for matchCase
    2) FindMatchingEntry uses bLazy as !matchCase
    but when bLazy = false, no autocomplete can work since you must type the
whole word
    so just use "entryCombo" startsWith "typed string" instead of "entryCombo"
== "typed string"


Point 1: that's probably exactly what introduced this bug.

Point 2: there seems to be some confusion in the code. "bLazy" seems to mean
"do exact match only, not autocomplete". Let's see how it is called from
vcl/source/control/combobox.cxx, function void
ComboBox::Impl::ImplAutocompleteHandler( Edit* pEdit )


        sal_Int32 nPos = LISTBOX_ENTRY_NOTFOUND;
        if (!m_isMatchCase)
        {
            // Try match case insensitive from current position
            nPos = m_pImplLB->GetEntryList()->FindMatchingEntry( aStartText,
nStart, bForward );
            if ( nPos == LISTBOX_ENTRY_NOTFOUND )
                // Try match case insensitive, but from start
                nPos = m_pImplLB->GetEntryList()->FindMatchingEntry(
aStartText,
                    bForward ? 0 :
(m_pImplLB->GetEntryList()->GetEntryCount()-1),
                    bForward );
        }

        if ( nPos == LISTBOX_ENTRY_NOTFOUND )
            // Try match full from current position
            nPos = m_pImplLB->GetEntryList()->FindMatchingEntry( aStartText,
nStart, bForward, false );
        if ( nPos == LISTBOX_ENTRY_NOTFOUND )
            //  Match full, but from start
            nPos = m_pImplLB->GetEntryList()->FindMatchingEntry( aStartText,
                bForward ? 0 : (m_pImplLB->GetEntryList()->GetEntryCount()-1),
                bForward, false );



There, bLazy seems to be used to ask for a *full* match, not a prefix match. I'
don't understand why, but the comments make that intent clear.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to