Re: [Libreoffice-commits] core.git: Shall this produce a string representation of a number?

On Fri, Jun 19, 2015 at 11:49:43AM +0200, Stephan Bergmann wrote:

> Do you happen to have insight into this, how to trigger the code? (Found in
> preparation for <https://gerrit.libreoffice.org/#/c/16371/> "Catch
> inadvertent uses of OUString(sal_Unicode) ctor.")

This seems to be called only in OTabFieldCellModifiedUndoAct::Undo()
(file dbaccess/source/ui/querydesign/QueryTabWinUndoAct.cxx), so my
guess is:

1) In an odb file, edit a query in design mode.
2) Change the contents of a cell of the "Sort" row.
3) Undo that change (menu edit/undo or ctrl-z). Probably *after*
   saving the content of that cell (by switching focus to another
   cell).

I'm unclear what this string (index) refers to, though.

However, it seems "normal" to me that whatever happens in
GetCellContents should be consistent with what happens in
SetCellContents, especially since OTabFieldCellModifiedUndoAct::Undo
seems to setup things to call (at a later time) SetCellContents with
as aregument whatever GetCellContents returned.

In SetCellContents, strNewText.toInt32() is called, which suggests
that your below change is correct.


I have some difficulty to fully match what happens in GetCellContents
vs SetCellContents (in the BROW_ORDER_ROW case); since SetCellContents
calls "pEntry->SetOrderDir", I would have expected "GetCellContents"
to call "pEntry->GetOrderDir". *Maybe* this all relies on the
"accident" fact that "enum EOrderDir" is "0, 1, 2" and that the
corresponding entries in the listbox are in the same order, so that
(in the listbox) *index* n is also *value*" n, for n being 0, 1 or 2.


> On 06/19/2015 11:04 AM, Stephan Bergmann wrote:
> > commit e46e8d19458fd64ff20b1013e5eeabd07e62379c
> > Author: Stephan Bergmann <sbergman@redhat.com>
> > Date:   Fri Jun 19 10:11:31 2015 +0200
> >
> >     Shall this produce a string representation of a number?
> >
> >     On the one hand, the code had apparently treated nIdx as a sal_Unicode character
> >     value ever since its inception in e718950884fa2db240822e1711f301b39a70ad3e "new
> >     querydesign."  On the other hand, the preceding BROW_VIS_ROW case does produce
> >     strings "0" and "1".
> >
> >     Change-Id: Ife6e98ba32146cc469b722fa4f013c12152b5505
> >
> > diff --git a/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx 
> > b/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
> > index 64ecc68..954638d 100644
> > --- a/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
> > +++ b/dbaccess/source/ui/querydesign/SelectionBrowseBox.cxx
> > @@ -2245,7 +2245,7 @@ OUString OSelectionBrowseBox::GetCellContents(sal_Int32 nCellIndex, 
> > sal_uInt16 n
> >              sal_Int32 nIdx = m_pOrderCell->GetSelectEntryPos();
> >              if (nIdx == LISTBOX_ENTRY_NOTFOUND)
> >                  nIdx = 0;
> > -            return OUString(nIdx);
> > +            return OUString::number(nIdx);
> >          }
> >          default:
> >              return GetCellText(nCellIndex, nColId);