Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] fix for fdo#46230, shrink the copy area only in the text export

[Tor Lillqvist]

> It would be good to get these two patches into 3.5.2 since they solve
> a really annoying bug.

Cherry-picked to the -3-5 branch.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW 3-5] [CHERRY-PICKED-3-5] Confirm File Format dialog at large font sizes

[Tor Lillqvist]

> Please cherry-pick to libreoffice-3-5 branch. Before/After screenshot is
> attached.

The screenshot was convincing ;), cherry-picked.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Re: [Libreoffice-commits] .: svx/inc

[Tor Lillqvist]

>  Somebody please signoff and push this to 3-5 too, there's the same
> compilation problem according to tinderbox.

Done.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW for 3.5] Fix redundant assignment of "nAngle" in switch in svx

[Tor Lillqvist]

> Can I cherry-pick this commit 49d7d4b3255f731ce9a8b5256da25f6a9bf53169 to
> 3.5 ?

Any idea what the visual impact of this change is? Who knows, maybe
the calling code actually expects the apparently nonsense semantics by
now;)

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Remove nasty xor hack for non-Mac vclcanvas

[Tor Lillqvist]

Done.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Clear whole layer in slideshow sprites fdo#45219

[Tor Lillqvist]

Cherry-picked.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Clear sprites to white fdo#45219.

[Tor Lillqvist]

Cherry-picked this one, too.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Clear full sprite area for fdo#45219

[Tor Lillqvist]

Cherry-picked to the 3-5 branch.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure on Windows/MSVC because of embedserv

[Lubos Lunak]

On Monday 19 of March 2012, Matúš Kukan wrote:
> On 18 March 2012 21:03, Lubos Lunak  wrote:
> >  MSVC/Windows build fails at the very end with an error about emserlo.dll
> > missing, probably caused by the recent embedserv conversion to gbuild. As
> > this is seem to be build-system related, I'm at loss. Since there
> > currently doesn't seem to be any usable MSVC tinderbox, I've pasted at
> > http://pastebin.ca/2129689 the log for 'make'
>
> hopefully fixed by
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=46dbbe4bc1d53f1e38f
>c7c407f6d5b5ebb2ae708

 Yes, that works, thanks. My first successfully finished Windows/MSVC build, 
now where's the champagne :) ?

> The problem with Windows builds is that build sometimes freezes.
> I don't know how to debug that. There were dmake, make, perl
> processes 'running' but with 0% CPU consuming.
> Maybe also Voreppe suffers from this.

 Oh, I see. I've already noticed this myself, and that's a good explanation 
for Voreppe's (lack of) builds. That's a rather bad bug for tinderbox builds, 
and we really could use a tinderbox watching over our commits breaking the 
MSVC build (I think I fixed 5 MSVC regressions last week at the very least).

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Use transparency for gradients fdo#45219

[Tor Lillqvist]

Cherry-picked this too.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Noel Grandin]

On 2012-03-19 08:27, Lubos Lunak wrote:
That said, I myself dislike the buffer class. I doubt its 
preallocation is a significant requirement for good performance 
(especially given it's only 16 characters). I


Even in Java, it's a code smell to allocate a StringBuffer object 
without specifying a pre-allocation size.


Might make a good EasyHack to go through the code and change the places 
that allocate OUStringBuffer to give them a reasonable initial size?


Regards, Noel Grandin

Disclaimer: http://www.peralex.com/disclaimer.html


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Return proper transparency value even for ignore_color.

[Tor Lillqvist]

Sounds sane, looks fine, cherry-picked to -3-5.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Lubos Lunak]

On Sunday 18 of March 2012, Olivier Hallot wrote:
> Thanks Rafael
>
> Any suggestion for the same issue for OUStringBuffer?

 First of all, what code would need such additions to OUStringBuffer? The two 
classes are modeled after Java's strings, where the idea is that the normal 
string is ... well, the normal string, and the buffer string is for creating 
new strings. Therefore, in theory, you do not need querying functionality in 
OUStringBuffer. In practice, as it happens, theory and practice are not quite 
the same :). So, if justified, I don't think there'd be any practical reasons 
against duplicating OUString methods in OUStringBuffer, they would be small 
inline functions calling the same functionality anyway.

 That said, I myself dislike the buffer class. I doubt its preallocation is a 
significant requirement for good performance (especially given it's only 16 
characters).  I think a much better and simpler solution would be to drop the 
buffer class and instead add reserve() to the string class for the cases 
where it would matter. Hopefully when we can break the ABI.

 Or, actually, seeing that _rtl_uString is marked as internal by the doxygen 
doc, it looks like it might be doable even now. Something to add to my TODO 
list for making the string classes actually nice to use :).

> Em 18-03-2012 10:46, Rafael Dominguez escreveu:
> > Theres no need, OUString already has a method lastIndexOf,
> > http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133
> >
> > On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot
> >  > > wrote:
> >
> > Hi all
> >
> > I put forefront that I am a newbie on C++ so, forgive me if I ask things
> > too basic or dumb. I was looking into the replacement of String by
> > OUString/OUStringBuffer in some parts of the code (starmath).
> >
> > First, I'd like a pointer on a text/discussion on why this is
> > necessary/recomended.(*)

 The String class is deprecated. There's nothing to gain from having 2 classes 
for the same purpose, perhaps besides headaches.

> > Secondly, as expected, some of the members of class String don't exist
> > in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
> > member in the classes where I need them. So far, so good.
> >
> > But such critical class, used all over the code, need a bit more care
> > and sponsorship, so with the specific case of
> > STRING::SearchBackward(...), is it OK to add a new member in
> > rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> > to OUStringBuffer::SearchBackward(...)?

 No. As said above, if the addition is justified, for consistency it should be 
modeled after OUString, not String.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Another partial fix for fdo#45219

[Tor Lillqvist]

I certainly don't know the code in question, but I trust you, so
cherry-picked to -3-5...

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] [CHERRY-PICKED-3-5] Consistent use of alpha in cairocanvas

[Tor Lillqvist]

Looked fine, cherry-picked to -3-5.

--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Missing sub-menu arrows with 3.5.x and GTK < 2.15

[David Bolen]

Using LO 3.5.x on a system with GTK < 2.15.0 loses all the sub-menu icons,
because there is no menu item arrow-scaling property until then, so the
code introduced in commit 948c14ee appears to scale the arrows to 0%.

I realize that's a pretty old GTK version, but I ran into this on my Ubuntu
8.04 LTS system (GTK 2.12.9) and assume there are some others (like RHEL)
that will have older versions for a while.  Plus, the requirements page on
the LO web site still lists GTK 2.10 as the requirement.

Attached is a small patch that restores the arrow icons when running
against GTK < 2.15.0, essentially by picking an arbitrary (but reasonable
in my tests) default scaling.  I also check before attempting to retrieve
the arrow-scaling style to avoid a bunch of GTK runtime warning messages,
but it works fine too if only the default scaling line is changed since GTK
doesn't change the variable contents for an unknown style.

-- David


gtk-submenu-icon.patch
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Rafael Dominguez]

Well OUStringBuffer dont seems to be the correct class to add that type of
functionality, but maybe someone else
can point you in the right direction.

On Sun, Mar 18, 2012 at 1:45 PM, Olivier Hallot <
olivier.hal...@documentfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thanks Rafael
>
> Any suggestion for the same issue for OUStringBuffer?
>
> Kind  regards
>
> Ikuvuer
>
> Em 18-03-2012 10:46, Rafael Dominguez escreveu:
> > Theres no need, OUString already has a method lastIndexOf,
> > http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133
> >
> > On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot
> >  > > wrote:
> >
> > Hi all
> >
> > I put forefront that I am a newbie on C++ so, forgive me if I ask things
> > too basic or dumb. I was looking into the replacement of String by
> > OUString/OUStringBuffer in some parts of the code (starmath).
> >
> > First, I'd like a pointer on a text/discussion on why this is
> > necessary/recomended.(*)
> >
> > Secondly, as expected, some of the members of class String don't exist
> > in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
> > member in the classes where I need them. So far, so good.
> >
> > But such critical class, used all over the code, need a bit more care
> > and sponsorship, so with the specific case of
> > STRING::SearchBackward(...), is it OK to add a new member in
> > rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> > to OUStringBuffer::SearchBackward(...)?
> >
> > Any better idea?
> >
> > Please advise.Thanks!
> >
> > (*) http://wiki.documentfoundation.org/Development/String_Classes
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > 
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
> >
> >
> >
> >
> > ___
> > LibreOffice mailing list
> > LibreOffice@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
> - --
> Olivier Hallot
> Founder, Board of Directors Member - The Document Foundation
> LibreOffice translation leader for Brazilian Portuguese
> +55-21-8822-8812
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPZiYsAAoJEJp3R7nH3vLxwYYH/iguXXkf8WqLnAn2UL90nstO
> MYCSpDC06Wadpp8/Y7RQVXiy+54/MK1uOZXfbDP6RSJ5yYPfIkILN3EEIkvn19zk
> 1HPgU18HLGE2nboSM/+/joCYsQZb8EXAjv9d2U16+JOB0bOam7tgzGKNCntMARft
> SIMsjw8Xp2hpo+z2W6YdwaUWOSUdHP9yr+ziWCFx2QCGFCkgY5voIJZtyGXCir9c
> 1AwzVc+A2IDIs4it14VVPojdmevYpm2frxub3Vh0qoeEOQFuFYs71zZe2SHfv45t
> jeIfdZGVMK8EsCoW8E4TvkjKhBts7mKkZkAMc2erkw1pSWuu8oqq+VkT+iTGKBc=
> =Xvp9
> -END PGP SIGNATURE-
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Fix for Bug 43895: Never let users save in /tmp by default

[Andrzej J. R. Hunt]

Hi,

Here is a my first attempt at a patch, fixing Bug 43895 (Never let users 
save in /tmp by default).


I was debating adding a warning for anyone saving to /tmp, however I 
doubt anyone would do this accidentally except in the case of 
downloading through firefox, which is now fixed. (Incidentally Chromium 
and Rekonq don't seem to allow direct opening of files -- they force the 
user to save the file first -- so this fix is pretty much firefox specific).


(Contributed under the LGPLv3+ / MPL.)

Regards,

Andrzej Hunt
diff --git a/sfx2/source/dialog/filedlghelper.cxx b/sfx2/source/dialog/filedlghelper.cxx
index 3bf4fb5..00d53be 100644
--- a/sfx2/source/dialog/filedlghelper.cxx
+++ b/sfx2/source/dialog/filedlghelper.cxx
@@ -26,6 +26,7 @@
  *
  /
 
+#include 
 #include 
 #include 
 #include 
@@ -1635,6 +1636,21 @@ void FileDialogHelper_Impl::getRealFilter( String& _rFilter ) const
 }
 }
 
+void FileDialogHelper_Impl::verifyPath()
+{
+struct stat aFileStat;
+const char* pFullPath = OUStringToOString( ( maPath.copy(7) + maFileName ),
+osl_getThreadTextEncoding() ).getStr();
+stat( pFullPath, &aFileStat );
+// Check that the file has read only permission and is in /tmp -- this is
+//  the case if we have opened the file from the web with firefox only.
+if ( maPath.compareTo("file:///tmp",11) == 0 &&
+( aFileStat.st_mode & (S_IRWXO + S_IRWXG + S_IRWXU) ) == S_IRUSR ) {
+maPath = SvtPathOptions().GetWorkPath();
+mxFileDlg->setDisplayDirectory( maPath );
+}
+}
+
 // 
 void FileDialogHelper_Impl::displayFolder( const ::rtl::OUString& _rPath )
 {
@@ -1648,6 +1664,7 @@ void FileDialogHelper_Impl::displayFolder( const ::rtl::OUString& _rPath )
 try
 {
 mxFileDlg->setDisplayDirectory( maPath );
+verifyPath();
 }
 catch( const IllegalArgumentException& )
 {
@@ -1665,6 +1682,7 @@ void FileDialogHelper_Impl::setFileName( const ::rtl::OUString& _rFile )
 try
 {
 mxFileDlg->setDefaultName( maFileName );
+verifyPath();
 }
 catch( const IllegalArgumentException& )
 {
diff --git a/sfx2/source/dialog/filedlgimpl.hxx b/sfx2/source/dialog/filedlgimpl.hxx
index 4f4e86d..149ac66 100644
--- a/sfx2/source/dialog/filedlgimpl.hxx
+++ b/sfx2/source/dialog/filedlgimpl.hxx
@@ -151,6 +151,8 @@ namespace sfx2
 voidSaveLastUsedFilter( void );
 
 voidimplInitializeFileName( );
+
+voidverifyPath( );
 
 voidimplGetAndCacheFiles( const ::com::sun::star::uno::Reference< XInterface >& xPicker  ,
   std::vector&   rpURLList,
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure on Windows/MSVC because of embedserv

[Matúš Kukan]

On 18 March 2012 21:03, Lubos Lunak  wrote:
>  MSVC/Windows build fails at the very end with an error about emserlo.dll
> missing, probably caused by the recent embedserv conversion to gbuild. As
> this is seem to be build-system related, I'm at loss. Since there currently
> doesn't seem to be any usable MSVC tinderbox, I've pasted at
> http://pastebin.ca/2129689 the log for 'make'

hopefully fixed by
http://cgit.freedesktop.org/libreoffice/core/commit/?id=46dbbe4bc1d53f1e38fc7c407f6d5b5ebb2ae708

The problem with Windows builds is that build sometimes freezes.
I don't know how to debug that. There were dmake, make, perl
processes 'running' but with 0% CPU consuming.
Maybe also Voreppe suffers from this.

Best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][REVIEW 3-5] fdo#46809 incomplete formula in formulabar

[Mat M]

Hello

Since Patchtool is around, marking thread :)

Mat M
Le Fri, 16 Mar 2012 21:29:10 +0100, Kohei Yoshida  
 a écrit:



On Fri, 2012-03-16 at 08:37 -0600, Noel Power wrote:

please see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e3b1592165d0513e90e28dfee92bc9db032fa221


Yes.  We already discussed this & did a thorough test yesterday on IRC.

I confirm that this change resolves the out-of-sync range input with
mouse between the cell and the input bar, and also does not re-introduce
a crash when typing Japanese via scim (which was the reason for the
change which introduced the regression).

Pushed to 3-5 with my sign off.

Kohei




--
Mat M
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Patchtool

[Josh Heidenreich]

Hi,

> That is why I asked if the source was available.

The code is now on GitHub.
https://github.com/TheJosh/patchtool

I'm going to keep working on it some more, and I'm wondering if it
should have a more permanent home on an official domain, although I
don't know who to talk to about that.

Cheers,
Josh
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

--- Comment #238 from Boostland  2012-03-18 15:19:11 PDT 
---
Add this long standing bug to the list please.

https://bugs.freedesktop.org/show_bug.cgi?id=40421";>Bug
40421 - 3.4.2 Draw with transparent layer loses bezier curves

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

About buggy behaviour which disappear when previous LO/OOo is removed

[julien2412]

Hello,

I try to help a little on bugs triaging or on IRC and found that quite a lot
of buggy behaviours could be resolved if previous LO/OOo profile was removed
(or backup if needed).
(eg : https://bugs.freedesktop.org/show_bug.cgi?id=45928)

In these cases, people are glad that the buggy behaviour isn't reproduced
but they don't understand why they have to do this whereas it's not
mentionned (or I missed it ?) in doc.

So here are some points.
1) why are there regularly problems with previous profile ? (perhaps it's
normal and can be easily explained so do not see any critics here, it's just
to understand and to inform people during bugs triaging)

2) should we add something in the doc like if troubleshooting ?
For example, to have more info on a bug, I suggest regularly these hints :
- try to remove/backup your LO profile
- disable any extensions for the test (I saw recently a pb which was in fact
due to Duden Korrector)
- do they reproduce the pb with brand new doc
- disable accessibility options if on Mac (quite new in my list, thank you
Alex :-) )
 
3) what can we do to allow a smoother LO upgrading :
detect problems with previous profile and :
- either to propose to bypass these + and to put default values
- backup previous profile and create a new one (of course the user should be
informed during the process)
(did I find a Gsoc subject ? :-) )

Julien.
PS : I thought about posting on doc/user but I wanted first devs opinions.

--
View this message in context: 
http://nabble.documentfoundation.org/About-buggy-behaviour-which-disappear-when-previous-LO-OOo-is-removed-tp3837359p3837359.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

fdo#42982, Working on the UNO RuntimeExceptions.

[Abeer Sethi]

I've updated this email as, thuswa(IRC nick).

I'm new to this and would be applying at GSOC, under the libre office
banner.

I was working on the RuntimeException, to understand a bit of the code and
how it works. I don't know whether I've got it correct but, here is the
link to the git diff.

Suggestions are welcome.

http://pastebin.com/raw.php?i=XAR4s81e

I have a few queries doesn't the RuntimeException support only 2 types of
constructor one with no parameters and one with only 1 string parameter.
Then, how does the original code have 2 exceptions listed? Was I supposed
to remove those 2 and add 1 string? I'm kind of confused. I've worked with
C++ but not too much with the Standard Library.

Thanking You,
Abeer Sethi
IRC : abeer/abeer_
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PUSHED][PATCH] Check iterator end in WW8TableCellGrid::addShadowCells

[Norbert Thiebaud]

On Sun, Mar 18, 2012 at 2:04 PM, Arnaud Versini
 wrote:
> Hi,
>
> This patch check iterator end before updating bBeginningOfCell and aRect.

Pushed, thanks

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

pointer to code

[M.Sharan Kumar]

hi all

i came across bug reporting.. and i am new to it.. its said that we need to
have a pointer to code in our description.. what does that mean??

-- 
Warm regards,
M.Sharan Kumar
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure on Windows/MSVC because of embedserv

[Lubos Lunak]

 Hello,

 MSVC/Windows build fails at the very end with an error about emserlo.dll 
missing, probably caused by the recent embedserv conversion to gbuild. As 
this is seem to be build-system related, I'm at loss. Since there currently 
doesn't seem to be any usable MSVC tinderbox, I've pasted at 
http://pastebin.ca/2129689 the log for 'make' after first running 'make 
embedserv.clean' (there's other stuff being needlessly rebuilt for whatever 
reason). At the end of the log there's also a find command showing that the 
library has been built, but not with the emserlo.dll name.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Check iterator end in WW8TableCellGrid::addShadowCells

[Arnaud Versini]

Hi,

This patch check iterator end before updating bBeginningOfCell and aRect.

Best regards

-- 
Arnaud Versini
From 3abb087caeb5e8a794720bd2fd1d7e9b97e8dc6c Mon Sep 17 00:00:00 2001
From: Arnaud Versini 
Date: Sun, 18 Mar 2012 19:59:55 +0100
Subject: [PATCH] Check iterator end WW8TableCellGrid

---
 sw/source/filter/ww8/WW8TableInfo.cxx |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/sw/source/filter/ww8/WW8TableInfo.cxx b/sw/source/filter/ww8/WW8TableInfo.cxx
index 6171430..72993ba 100644
--- a/sw/source/filter/ww8/WW8TableInfo.cxx
+++ b/sw/source/filter/ww8/WW8TableInfo.cxx
@@ -1171,9 +1171,11 @@ void WW8TableCellGrid::addShadowCells()
 }
 
 ++aCellIt;
-
-bBeginningOfCell = (aRect.Left() != aCellIt->left());
-aRect = aCellIt->getRect();
+if (aCellIt != aCellEndIt)
+{
+bBeginningOfCell = (aRect.Left() != aCellIt->left());
+aRect = aCellIt->getRect();
+}
 }
 
 WW8TableCellGridRow::Pointer_t pRow = getRow(*aTopsIt);
-- 
1.7.5.4

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Rafael

Any suggestion for the same issue for OUStringBuffer?

Kind  regards

Ikuvuer

Em 18-03-2012 10:46, Rafael Dominguez escreveu:
> Theres no need, OUString already has a method lastIndexOf,
> http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133
> 
> On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot
>  > wrote:
> 
> Hi all
> 
> I put forefront that I am a newbie on C++ so, forgive me if I ask things
> too basic or dumb. I was looking into the replacement of String by
> OUString/OUStringBuffer in some parts of the code (starmath).
> 
> First, I'd like a pointer on a text/discussion on why this is
> necessary/recomended.(*)
> 
> Secondly, as expected, some of the members of class String don't exist
> in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
> member in the classes where I need them. So far, so good.
> 
> But such critical class, used all over the code, need a bit more care
> and sponsorship, so with the specific case of
> STRING::SearchBackward(...), is it OK to add a new member in
> rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> to OUStringBuffer::SearchBackward(...)?
> 
> Any better idea?
> 
> Please advise.Thanks!
> 
> (*) http://wiki.documentfoundation.org/Development/String_Classes
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> 
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
> 
> 
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPZiYsAAoJEJp3R7nH3vLxwYYH/iguXXkf8WqLnAn2UL90nstO
MYCSpDC06Wadpp8/Y7RQVXiy+54/MK1uOZXfbDP6RSJ5yYPfIkILN3EEIkvn19zk
1HPgU18HLGE2nboSM/+/joCYsQZb8EXAjv9d2U16+JOB0bOam7tgzGKNCntMARft
SIMsjw8Xp2hpo+z2W6YdwaUWOSUdHP9yr+ziWCFx2QCGFCkgY5voIJZtyGXCir9c
1AwzVc+A2IDIs4it14VVPojdmevYpm2frxub3Vh0qoeEOQFuFYs71zZe2SHfv45t
jeIfdZGVMK8EsCoW8E4TvkjKhBts7mKkZkAMc2erkw1pSWuu8oqq+VkT+iTGKBc=
=Xvp9
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW-3-5] fix for fdo#40426, import all properties into ScDBData

[Markus Mohrhard]

Hey,

with [1] we import all parameters into ScDBData. Before that we
imported bByRow and bHasHeader only into the QueryParam and used the
default values in ScDBData. The properties in ScDBData are the ones
that are actually the used ones and the ones in ScSortParam and
ScQueryParam are always copied from ScDBData.

This patch is simple and safe and I think we can included it into 3-5.

Regards,
Markus

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed88b144ce24b9a733d4a9ab6614307c96537baa
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [REVIEW-3-5] fix for fdo#46230, shrink the copy area only in the text export

[Markus Mohrhard]

Hey,

2012/3/16 Markus Mohrhard :
> Hello Michael,
>
>> On Tue, 2012-03-13 at 01:41 +0100, Markus Mohrhard wrote:
>>> calc. The problem is that we should not shrink the area already in
>>> ScTransferObj. We should wait until we need to export the data and
>>> limit this to the text export. Please test it especially in the
>>> context of n#677811.
>>
>>        I see one of Rainer's favorite bugs already has a patch; but - since
>> you've pushed it to master, were you asking for review for -3-5 ?
>
> I was asking for review and Muthu or Kohei to check that the private
> Novell bug is not affected by this patch since I this time chose a
> more aggressive fix to finally eliminate all problems around
> copy/paste & dnd to internal and external applications.
>
>> re-titling to that for now ...
>
> Oh I always thought that [REVIEW] is the correct tag for current
> stable branch and [PATCH] for master but if not I will adapt this.
>
>>
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a26fe4a39b6f3b2af269b801340c32c28806250
>>
>>        It looks reasonable to me, if so :-)
>>
>
> According to Muthu I might need a follow-up patch for n#677811 because
> Outlook seems to use the HTML export and not the text export.
>

So with 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ee518863337fba9bce019e05e24f527617a4321
we should now have solved all problems at once. We now allow to
copy/paste the content to external applications and shrink the area in
case of text unconditionally and in case of HTML in case of a whole
selected row or column.

I think this solution is sane and safe. We no longer mess around with
the internal copy/paste document and only adjust the cases that are
really useful and needed.

It would be good to get these two patches into 3.5.2 since they solve
a really annoying bug.

Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Cppcheck reports "Logical disjunction always evaluates to true" in sdext module

[julien2412]

Hello,

Cppcheck reports this in sdext module :
[source/minimizer/optimizerdialog.cxx:276]: (warning) Logical disjunction
always evaluates to true: nNewStep >= 0 || nNewStep <= 4
Here is the line :
if ( ( nNewStep != mnCurrentStep ) && ( ( nNewStep <= MAX_STEP ) || (
nNewStep >= 0 ) ) )

Shouldn't it be :
if ( ( nNewStep != mnCurrentStep ) && ( nNewStep <= MAX_STEP ) && ( nNewStep
>= 0 ) )
?
Moreover, if I'm right, should we additionnally throw an exception (which
one ?) if "nNewStep" is not between 0 and MAX_STEP 

If ok for just the condition change, I can commit and push on master (what
about 3.5 ?)
About the exception, I don't know what to put.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-reports-Logical-disjunction-always-evaluates-to-true-in-sdext-module-tp3836919p3836919.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Template translation / shrink bloated install size

[Hasitha Dhananjaya]

Hi all,

I'm a second year undergraduate student from University of Moratuwa.
I would like to join GSocC 2012 to following project.
*Template translation / shrink bloated install size*
I have followed Java course and now I'm following C++ course. So I think I
can contribute for this project and I try to do my best.
I got this project idea from this link.
https://wiki.documentfoundation.org/Development/Gsoc/Ideas

Thank you.
Hasitha Dhananjaya
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

LibreOffice writer - GSoC 2012 idea proposal

[sharan_kumar]

hi all,

i am a student applicant for the gsoc 2012. i saw the projects proposed by
libreoffice. But finally came up with my own idea. My idea is "content based
search for file".. ie. we can search for files having certain contents.. it
searches all *.odt files and displays those files, which has the specified
contents in them.. is the proposal a feasible one for gsoc and will anyone
mentor this proposal?

Warm regards,
M.Sharan Kumar


--
View this message in context: 
http://nabble.documentfoundation.org/LibreOffice-writer-GSoC-2012-idea-proposal-tp3836807p3836807.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Seeking advice on vcl sizing

[Andrew Higginson]

Hi,

I need some advice with sizing of controls and windows on vcl

So for the about dialog, currently I am setting its size based on the width
of the user's screen (e.g. 1/3 of the screen)

Then I am sizing all the controls relative to this, and finally at the end,
checking that they all fit (and if not resize as appropriate)

What I wanted to ask was, is basing the size of the about dialog on the
size of the screen the best idea? Or should I be doing it another way,
based on the font size for example?

Thanks,

-- 
Andrew Higginson
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[REVIEW for 3.5] Fix redundant assignment of "nAngle" in switch in svx

[julien2412]

Hello,

In svx cppcheck reports this :
[source/items/algitem.cxx:183]: (warning) Redundant assignment of "nAngle"
in switch
Here are the lines :
switch( static_cast< SvxCellOrientation >( GetValue() ) )
{
case SVX_ORIENTATION_BOTTOMTOP: nAngle = 9000;
case SVX_ORIENTATION_TOPBOTTOM: nAngle = 27000;
default: ; //prevent warning
}

It 's been there since the commit 56ce215d39efdb96703a53b7b51c9c5a0d61c9f1
(02/08/2004)

Can I cherry-pick this commit 49d7d4b3255f731ce9a8b5256da25f6a9bf53169 to
3.5 ?

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/REVIEW-for-3-5-Fix-redundant-assignment-of-nAngle-in-switch-in-svx-tp3836734p3836734.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

--- Comment #237 from Rainer Bielefeld  
2012-03-18 08:18:41 PDT ---
Adding "Bug 45081 - SLIDESHOW CRASH on slide with embedded / linked video"
(replaces Bug 44011)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Bug 37361] LibreOffice 3.5 most annoying bugs

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37361

Rainer Bielefeld  changed:

   What|Removed |Added

 Depends on|44011   |

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PUSHED] Re: Cppcheck reports "Same expression on both sides of '=='" on dpitemdata.cxx

[Julien Nabet]

On 18/03/2012 15:07, Ivan Timofeev wrote:

Hi

On 18.03.2012 12:41, julien2412 wrote:
Just to make notice that Cppcheck reports "Same expression on both 
sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the 
lines :

...

 216 if (mbStringInterned && r.mbStringInterned)
 217 return mpString == mpString;< HERE


Wow! There definitely must be "return mpString == r.mpString". 
Probably Kohei would like to redo his performance tests...


Do you prefer to push fixes yourself? :)

Fix pushed and commited on master (2b24cfe22d5d29645d2d926251c29514887fe3a9)

Thank you for the review ! :-)

Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

LibreOffice / license ...

[Robert Nagy]

All of my past & future contributions to LibreOffice may be
licensed under the MPL/LGPLv3+ dual license, including the
go-oo code
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Convert SV_DECL_VARARR, SV_IMPL_VARARR with std::deque

[Bartosz]

Hi

I converted the SV VARARR to std::deque in sw component.

Could you please check and push this path?

This and later contributions is licensed under MPL 1.1 / GPL v3+ / LGPL v3+.

Best Regards
Bartosz

From 722e5a0e2917dd173ff2781da6a420f97d126310 Mon Sep 17 00:00:00 2001
From: Bartosz Kosiorek 
Date: Fri, 16 Mar 2012 20:47:09 +0100
Subject: [PATCH 3/3] Conver SV VARARR to std::deque for sw module.

---
 sw/source/core/layout/paintfrm.cxx |  143 ---
 1 files changed, 65 insertions(+), 78 deletions(-)

diff --git a/sw/source/core/layout/paintfrm.cxx 
b/sw/source/core/layout/paintfrm.cxx
index dac3e27..381a24a 100644
--- a/sw/source/core/layout/paintfrm.cxx
+++ b/sw/source/core/layout/paintfrm.cxx
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -48,7 +47,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -81,7 +79,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,14 +96,14 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #define COL_NOTES_SIDEPANE  RGB_COLORDATA(230,230,230)
 #define COL_NOTES_SIDEPANE_BORDER   RGB_COLORDATA(200,200,200)
 #define COL_NOTES_SIDEPANE_SCROLLAREA   RGB_COLORDATA(230,230,220)
 
-#include 
+#include  //Need for svtools::DrawLine
+#include  //Need for svtools::DrawLine
 
 #include "pagefrm.hrc"
 #include 
@@ -124,6 +121,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -132,8 +130,6 @@
 using namespace ::editeng;
 using namespace ::com::sun::star;
 
-#define GETOBJSHELL()   ((SfxObjectShell*)rSh.GetDoc()->GetDocShell())
-
 //subsidiary lines enabled?
 #define IS_SUBS_TABLE \
 (pGlobalShell->GetViewOptions()->IsTable() && \
@@ -156,8 +152,6 @@ using namespace ::com::sun::star;
   !pGlobalShell->GetViewOptions()->IsFormView() &&\
SwViewOption::IsObjectBoundaries())
 
-#define SW_MAXBORDERCACHE 20
-
 //Class declaration; here because they are only used in this file
 
 #define SUBCOL_PAGE 0x01//Helplines of the page
@@ -194,25 +188,24 @@ public:
 sal_Bool MakeUnion( const SwRect &rRect );
 };
 
-SV_DECL_VARARR( SwLRects, SwLineRect, 100 )
-
-class SwLineRects : public SwLRects
+class SwLineRects : public std::deque< SwLineRect >
 {
-sal_uInt16 nLastCount;  //avoid unnecessary cycles in PaintLines
+std::deque< SwLineRect >::iterator nLastCount;  //avoid unnecessary cycles 
in PaintLines
 public:
-SwLineRects() : nLastCount( 0 ) {}
+SwLineRects() : nLastCount( this->begin() ) {}
 void AddLineRect( const SwRect& rRect,  const Color *pColor, const 
SvxBorderStyle nStyle,
   const SwTabFrm *pTab, const sal_uInt8 nSCol );
 void ConnectEdges( OutputDevice *pOut );
 void PaintLines  ( OutputDevice *pOut );
 void LockLines( sal_Bool bLock );
 
-sal_uInt16 Free() const { return nFree; }
+//Limit lines to 100
+bool isFull() const { return this->size()>100 ? true : false; }
 };
 
 class SwSubsRects : public SwLineRects
 {
-void RemoveSuperfluousSubsidiaryLines( const SwLineRects &rRects ); //;-)
+void RemoveSuperfluousSubsidiaryLines( const SwLineRects &rRects );
 public:
 void PaintSubsidiary( OutputDevice *pOut, const SwLineRects *pRects );
 
@@ -414,7 +407,6 @@ SwSavePaintStatics::~SwSavePaintStatics()
 
 //- Implementation for the table borders --
 
-SV_IMPL_VARARR( SwLRects, SwLineRect );
 
 SwLineRect::SwLineRect( const SwRect &rRect, const Color *pCol, const 
SvxBorderStyle nStyl,
 const SwTabFrm *pT, const sal_uInt8 nSCol ) :
@@ -474,9 +466,10 @@ void SwLineRects::AddLineRect( const SwRect &rRect, const 
Color *pCol, const Svx
 
 //Loop backwards because lines which can be combined, can usually be 
painted
 //in the same context.
-for ( sal_uInt16 i = Count(); i ; )
+
+for (SwLineRects::iterator it = this->end(); it != this->begin(); --it)
 {
-SwLineRect &rLRect = operator[](--i);
+SwLineRect &rLRect = (*it);
 // Test for the orientation, color, table
 if ( rLRect.GetTab() == pTab &&
  !rLRect.IsPainted() && rLRect.GetSubColor() == nSCol &&
@@ -488,7 +481,7 @@ void SwLineRects::AddLineRect( const SwRect &rRect, const 
Color *pCol, const Svx
 return;
 }
 }
-Insert( SwLineRect( rRect, pCol, nStyle, pTab, nSCol ), Count() );
+this->push_back( SwLineRect( rRect, pCol, nStyle, pTab, nSCol ) );
 }
 
 void SwLineRects::ConnectEdges( OutputDevice *pOut )
@@ -504,9 +497,9 @@ void SwLineRects::ConnectEdges( OutputDevice *pOut )
 
 SvPtrarr   aCheck( 64 );
 
-for ( int i = 0; i < (int)Count(); ++i )
+for (SwLineRects::iterator it = this->begin(); it != this->end(); ++it)
 {
-SwLineRect &rL1 = operator[](sal_uInt16(i));
+SwLineRect &rL1 = (*it);
 if ( !rL

Re: Cppcheck reports "Same expression on both sides of '=='" on dpitemdata.cxx

[Ivan Timofeev]

Hi

On 18.03.2012 12:41, julien2412 wrote:

Just to make notice that Cppcheck reports "Same expression on both sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the lines :

...

 216 if (mbStringInterned && r.mbStringInterned)
 217 return mpString == mpString;< HERE


Wow! There definitely must be "return mpString == r.mpString". Probably 
Kohei would like to redo his performance tests...


Do you prefer to push fixes yourself? :)

Thanks!!!

Ivan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Ivan Timofeev]

On 18.03.2012 17:46, Rafael Dominguez wrote:

Theres no need, OUString already has a method lastIndexOf,


added to the wiki :)

Regards,
Ivan

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Strings

[Rafael Dominguez]

Theres no need, OUString already has a method lastIndexOf,
http://opengrok.libreoffice.org/xref/core/sal/inc/rtl/ustring.hxx#1133

On Sun, Mar 18, 2012 at 1:06 PM, Olivier Hallot <
olivier.hal...@documentfoundation.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all
>
> I put forefront that I am a newbie on C++ so, forgive me if I ask things
> too basic or dumb. I was looking into the replacement of String by
> OUString/OUStringBuffer in some parts of the code (starmath).
>
> First, I'd like a pointer on a text/discussion on why this is
> necessary/recomended.(*)
>
> Secondly, as expected, some of the members of class String don't exist
> in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
> member in the classes where I need them. So far, so good.
>
> But such critical class, used all over the code, need a bit more care
> and sponsorship, so with the specific case of
> STRING::SearchBackward(...), is it OK to add a new member in
> rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
> to OUStringBuffer::SearchBackward(...)?
>
> Any better idea?
>
> Please advise.Thanks!
>
> (*) http://wiki.documentfoundation.org/Development/String_Classes
> - --
> Olivier Hallot
> Founder, Board of Directors Member - The Document Foundation
> LibreOffice translation leader for Brazilian Portuguese
> +55-21-8822-8812
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPZd3PAAoJEJp3R7nH3vLxygcH/2QgJQth4OfLcZHt0eh+LnR0
> Pu/pOjcsS9iFMuKyd2C4zAATK4KuuUByj4speBlCXFRnRwyIoDSQAKJiJhnk+SNc
> vQhlWrn+yTzB8wS2Ps8ryARcMiM80ho6Gs3sNzh+tHo+svZLR8KQx2qwcaPPAIZ1
> a1WESHMcjRbOZ4PhYPo5CTEoH9ePSfpOIDeyU+NmOplWQzs0ujkZqh85mT7AtCZh
> t82A6ke8gJgeG5HBRMqsUj2EY/1+Kd3OxGZwF1kaQn0hr5+o+MO8afl9FlXT0hiS
> aksX1ZvHejFDNClgLHfvLTeuEQx3xXR7Cc7vrpYXDJM5oIEO5CuW6f1B6Ni+mk8=
> =YYx7
> -END PGP SIGNATURE-
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] remove unused code (oox, sc)

[Petr Vorel]

Hi there,

some unused code removed (oox, sc).

Regards,
Petr

>From 3c03ddd6eb8e0cefa229f3874e3da35bd0a57788 Mon Sep 17 00:00:00 2001
From: Petr Vorel 
Date: Sat, 17 Mar 2012 20:25:52 +0100
Subject: [PATCH 1/2] remove unused code (oox, sc)

---
 oox/inc/oox/dump/dumperbase.hxx  |7 ---
 oox/inc/oox/dump/oledumper.hxx   |5 -
 oox/inc/oox/ole/vbacontrol.hxx   |2 --
 oox/source/dump/dumperbase.cxx   |   15 ---
 oox/source/dump/oledumper.cxx|7 ---
 oox/source/ole/vbacontrol.cxx|5 -
 sc/source/filter/inc/formulabase.hxx |3 ---
 sc/source/filter/oox/formulabase.cxx |9 -
 unusedcode.easy  |7 ---
 9 files changed, 0 insertions(+), 60 deletions(-)

diff --git a/oox/inc/oox/dump/dumperbase.hxx b/oox/inc/oox/dump/dumperbase.hxx
index 7cba7ae..534776b 100644
--- a/oox/inc/oox/dump/dumperbase.hxx
+++ b/oox/inc/oox/dump/dumperbase.hxx
@@ -993,8 +993,6 @@ public:
 inline const StorageRef& getRootStorage() const { return mxCfgData->getRootStorage(); }
 inline const ::rtl::OUString& getSysFileName() const { return mxCfgData->getSysFileName(); }
 
-voidsetStringOption( const String& rKey, const String& rData );
-
 const ::rtl::OUString& getStringOption( const String& rKey, const ::rtl::OUString& rDefault ) const;
 boolgetBoolOption( const String& rKey, bool bDefault ) const;
 template< typename Type >
@@ -1005,7 +1003,6 @@ public:
 
 template< typename ListType >
 ::boost::shared_ptr< ListType > createNameList( const String& rListName );
-voidsetNameList( const String& rListName, const NameListRef& rxList );
 voideraseNameList( const String& rListName );
 NameListRef getNameList( const String& rListName ) const;
 
@@ -1792,10 +1789,6 @@ public:
 const BinaryInputStreamRef& rxStrm,
 const ::rtl::OUString& rSysFileName );
 
-explicitBinaryStreamObject(
-const OutputObjectBase& rParent,
-const BinaryInputStreamRef& rxStrm );
-
 protected:
 voiddumpBinaryStream( bool bShowOffset = true );
 
diff --git a/oox/inc/oox/dump/oledumper.hxx b/oox/inc/oox/dump/oledumper.hxx
index 1a94e77..42abf2d 100644
--- a/oox/inc/oox/dump/oledumper.hxx
+++ b/oox/inc/oox/dump/oledumper.hxx
@@ -331,11 +331,6 @@ protected:
 const String& rPropNameList,
 bool b64BitPropFlags = false );
 voidconstruct(
-const OutputObjectBase& rParent,
-const BinaryInputStreamRef& rxStrm,
-const String& rPropNameList,
-bool b64BitPropFlags = false );
-voidconstruct(
 const InputObjectBase& rParent,
 const String& rPropNameList,
 bool b64BitPropFlags = false );
diff --git a/oox/inc/oox/ole/vbacontrol.hxx b/oox/inc/oox/ole/vbacontrol.hxx
index 4647245..b4d2afb 100644
--- a/oox/inc/oox/ole/vbacontrol.hxx
+++ b/oox/inc/oox/ole/vbacontrol.hxx
@@ -65,8 +65,6 @@ public:
 inline const AxPairData& getPosition() const { return maPos; }
 /** Returns the unique identifier of this control. */
 inline sal_Int32getId() const { return mnId; }
-/** Returns true, if the control is visible. */
-boolisVisible() const;
 /** Returns true, if this control is a container control. */
 boolisContainer() const;
 /** Returns the length of the stream data for stream based controls. */
diff --git a/oox/source/dump/dumperbase.cxx b/oox/source/dump/dumperbase.cxx
index 54159b440..f078111 100644
--- a/oox/source/dump/dumperbase.cxx
+++ b/oox/source/dump/dumperbase.cxx
@@ -1699,11 +1699,6 @@ void Config::construct( const sal_Char* pcEnvVar, const Reference< XComponentCon
 mxCfgData.reset( new SharedConfigData( OUString::createFromAscii( pcFileName ), rxContext, rxRootStrg, rSysFileName, rMediaDesc ) );
 }
 
-void Config::setStringOption( const String& rKey, const String& rData )
-{
-mxCfgData->setOption( rKey, rData );
-}
-
 const OUString& Config::getStringOption( const String& rKey, const OUString& rDefault ) const
 {
 const OUString* pData = implGetOption( rKey );
@@ -1726,11 +1721,6 @@ bool Config::isImportEnabled() const
 return getBoolOption( "enable-import", true );
 }
 
-void Config::setNameList( const String& rListName, const NameListRef& rxList )
-{
-mxCfgData->setNameList( rListName, rxList );
-}
-
 void Config::eraseNameList( const String& rListName )
 {
 mxCfgData->eraseNameList( rListName );
@@ -2837,11 +2827,6 @@ BinaryStreamObject::BinaryStreamObject( const ObjectBase& rParent, const BinaryI
 InputObjectBase::construct

Cppcheck reports "Logical conjunction always evaluates to false" in text_gfx.cxx

[julien2412]

Hello,

Cppcheck reports this :
[generic/print/text_gfx.cxx:105]: (warning) Logical conjunction always
evaluates to false: nChar < 65380 && nChar >= 65387

Here are the lines :
   103 if( ( nChar >= 0x3008 && nChar < 0x3019 && nChar != 0x3012 )
||
104 nChar == 0xff3b || nChar == 0xff3d ||
105 (nChar >= 0xff6b && nChar < 0xff64 ) ||
106 nChar == 0xffe3
107 )
108 nAngle = 0;

Shoud the line 105 just be replaced by :
 (nChar >= 0xff64 && nChar < 0xff6b ) ||

Or is it less obvious/more tricky than that ?

If ok, I can commit and push it on master of course.

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-reports-Logical-conjunction-always-evaluates-to-false-in-text-gfx-cxx-tp3836511p3836511.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: heads up excel filter bits moved to sc

[Matúš Kukan]

On 16 March 2012 13:44, Noel Power  wrote:
> One hack in the sc build is that I need to include the workdir/{platform
> dir}/oox/inc to pick up some generated headers. Is this nuts? is there a
> better way? Short of regenerating the same stuff in sc ( duplication )
> or making the oox generate the files into the solver directly I see no
> alternative

Maybe if you add oox/token/properties.hxx to oox/Package_generated.mk
you can remove -I$(WORKDIR)/oox/inc.
It will be in solver.

Best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

About Strings

[Olivier Hallot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all

I put forefront that I am a newbie on C++ so, forgive me if I ask things
too basic or dumb. I was looking into the replacement of String by
OUString/OUStringBuffer in some parts of the code (starmath).

First, I'd like a pointer on a text/discussion on why this is
necessary/recomended.(*)

Secondly, as expected, some of the members of class String don't exist
in O[U]String[Buffer]. Therefore I was advised by Norbert to create the
member in the classes where I need them. So far, so good.

But such critical class, used all over the code, need a bit more care
and sponsorship, so with the specific case of
STRING::SearchBackward(...), is it OK to add a new member in
rtl::OUStringBuffer? If so, is it OK to clone STRING:SearchBackward(...)
to OUStringBuffer::SearchBackward(...)?

Any better idea?

Please advise.Thanks!

(*) http://wiki.documentfoundation.org/Development/String_Classes
- -- 
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPZd3PAAoJEJp3R7nH3vLxygcH/2QgJQth4OfLcZHt0eh+LnR0
Pu/pOjcsS9iFMuKyd2C4zAATK4KuuUByj4speBlCXFRnRwyIoDSQAKJiJhnk+SNc
vQhlWrn+yTzB8wS2Ps8ryARcMiM80ho6Gs3sNzh+tHo+svZLR8KQx2qwcaPPAIZ1
a1WESHMcjRbOZ4PhYPo5CTEoH9ePSfpOIDeyU+NmOplWQzs0ujkZqh85mT7AtCZh
t82A6ke8gJgeG5HBRMqsUj2EY/1+Kd3OxGZwF1kaQn0hr5+o+MO8afl9FlXT0hiS
aksX1ZvHejFDNClgLHfvLTeuEQx3xXR7Cc7vrpYXDJM5oIEO5CuW6f1B6Ni+mk8=
=YYx7
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: heads up excel filter bits moved to sc

[Miklos Vajna]

On Fri, Mar 16, 2012 at 06:44:04AM -0600, Noel Power  wrote:
> I moved on-masse all the excel related ooxml import filter stuff from
> oox to sc ( scfilt to be precise ). This will allow us now to access
> core functionality on import rather than depending solely on UNO. 
> I managed to get a full build on linux, and partial ( but a least up to
> sc ) for mingw & windows. It's possible some other platforms might break
> so be aware.
> 
> One hack in the sc build is that I need to include the workdir/{platform
> dir}/oox/inc to pick up some generated headers. Is this nuts? is there a
> better way? Short of regenerating the same stuff in sc ( duplication )
> or making the oox generate the files into the solver directly I see no
> alternative

Don't worry about that, the ww8 import filter in sw includes generated
headers from oox as well.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Working on the UNO RuntimeExceptions. (easyhack fdo#42982)

[julien2412]

Hi again Abeer (I'm julien2412 from IRC),

I don't know if it's ok or not but just 2 slight remarks :
1) You should quote the easyhack (here fdo#42982,
https://bugs.freedesktop.org/show_bug.cgi?id=42982)
2) if you haven't already done it, could you please confirm that you
submitted your patch under
LGPL3+/MPL? (If you plan on doing more patches, please consider just
writing a blanket mail saying that you want to always commit under
these licenses and then add yourself to
https://wiki.documentfoundation.org/Development/Developers) You'll see an
example of the post here :
http://nabble.documentfoundation.org/License-statement-td3826815.html

Welcome to LO project :-)

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Working-on-the-UNO-RuntimeExceptions-tp3836329p3836386.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Add junit check fix to 3.5 branch

[Tomáš Chvátal]

Hi guys,

Please see commit [1] for merging to 3.5 branch, it needs hand update for 
s/$GREP/grep/ there.

Can I get signed-off from someone?

Cheers

Tom

[1] 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=86793aeed94d839251e1b1098d4c8389ab7a72ae

signature.asc
Description: This is a digitally signed message part.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: GSoC idea to improve LightProof

[Miklos Vajna]

Hi Daniel,

On Sun, Mar 18, 2012 at 01:15:01AM +0200, Коростіль Данило 
 wrote:
> I want to be honest. I was planed to be involved in LanguageTool
> project. Unfortunately, Google refused their application form for
> some reasons. I wasn't ready for that cruel turn. However I have big
> hope than I can switch to LightProof (because it's almost the same
> project). I have some experience of localization and languages
> rules. Actually I'm current Ukrainian coordinator of LO
> localization.
> 
> So I'm just spreading new idea. Is it acceptable as a task? I've
> already mailed to László Németh (creator of LightProof). Most likely
> he will be my mentor.
> 
> Also as Ukrainian, I want to add support of my language in LP and
> carry on working on LO localization process hardly.
> 
> Discuss! I'm ready to be flexible and loyal for any responses.

If the topic is LightProof, best to put Laszlo to CC. :)

Miklos
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Working on the UNO RuntimeExceptions.

[Abeer Sethi]

I'm new to this and would be applying at GSOC, under the libre office
banner.

I was working on the RuntimeException, to understand a bit of the code and
how it works. I don't know whether I've got it correct but, here is the
link to the git diff.

Suggestions are welcome.

http://pastebin.com/raw.php?i=XAR4s81e

Thanking You,
Abeer Sethi
IRC : abeer/abeer_
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice - GSoC 2012

[Alexander Wilms]

Hi,

Have you already completed an easy hack?

For the project you have chosen, Thorsten Behrens would probably your
mentor. He should be able to help you getting involved.

tbehrens @ suse . com

Regards

Alex

--
View this message in context: 
http://nabble.documentfoundation.org/LibreOffice-GSoC-2012-tp3836151p3836268.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Specifying a dependency with build?

[Matúš Kukan]

On 18 March 2012 09:33, Lubos Lunak  wrote:
>  what is the way to specify with gbuild that a target has another target as a
> dependency?

Something like:
$(call gb_AAA_get_target,aaa) : $(call gb_BBB_get_target,bbb)

In this case:
$(call gb_CppunitTest_get_target,sal_osl_module) : \
$(call gb_CppunitTest_get_target,Module_DLL)

in one of the two makefiles should solve the problem.

Best,
Matus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Replace SV_DECL_PTRARR_DEL by ptr_vector in ww8par2.cxx

[Arnaud Versini]

Hi,

This patch replace SV_DECL_PTRARR_DEL by a simple ptr_vector in
sw/source/filter/ww8/ww8par2.cxx. I will continue on the same way in this
folder if there is no issue with this patch.

I noticed with the RTF spec (doc file) a memory error (not due to this
patch) :

==5526== Invalid read of size 1
==5526==at 0x24F492F4: SVBT16ToShort(unsigned char const*) (solar.h:88)
==5526==by 0x24FF3547: SwWW8ImplReader::Read_UL(unsigned short,
unsigned char const*, short) (ww8par6.cxx:4180)
==5526==by 0x24FF5EEB: SwWW8ImplReader::ImportSprm(unsigned char
const*, unsigned short) (ww8par6.cxx:6140)
==5526==by 0x24FA6687: WW8RStyle::ImportSprms(unsigned char*, short,
bool) (ww8par2.cxx:3646)
==5526==by 0x24FA6736: WW8RStyle::ImportSprms(unsigned long, short,
bool) (ww8par2.cxx:3663)
==5526==by 0x24FA690A: WW8RStyle::ImportUPX(short, bool, bool)
(ww8par2.cxx:3720)
==5526==by 0x24FA69FC: WW8RStyle::ImportGrupx(short, bool, bool)
(ww8par2.cxx:3742)
==5526==by 0x24FA771A: WW8RStyle::Import1Style(unsigned short)
(ww8par2.cxx:3950)
==5526==by 0x24FA93CF: WW8RStyle::ImportNewFormatStyles()
(ww8par2.cxx:4461)
==5526==by 0x24FA9430: WW8RStyle::ImportStyles() (ww8par2.cxx:4469)
==5526==by 0x24FA94CC: WW8RStyle::Import() (ww8par2.cxx:4481)
==5526==by 0x24F77FF8: SwWW8ImplReader::CoreLoad(WW8Glossary*,
SwPosition const&) (ww8par.cxx:4474)
==5526==by 0x24F7B48D: SwWW8ImplReader::LoadThroughDecryption(SwPaM&,
WW8Glossary*) (ww8par.cxx:5144)
==5526==by 0x24F7C7CA: SwWW8ImplReader::LoadDoc(SwPaM&, WW8Glossary*)
(ww8par.cxx:5452)
==5526==by 0x24F7CBF3: WW8Reader::Read(SwDoc&, String const&, SwPaM&,
String const&) (ww8par.cxx:5541)
==5526==by 0x1EB8CD0A: SwReader::Read(Reader const&) (shellio.cxx:183)
==5526==by 0x1ECCD05B: SwDocShell::ConvertFrom(SfxMedium&)
(docsh.cxx:256)
==5526==by 0x6750747: SfxObjectShell::DoLoad(SfxMedium*)
(objstor.cxx:746)
==5526==by 0x679BEB5:
SfxBaseModel::load(com::sun::star::uno::Sequence
const&) (sfxbasemodel.cxx:1904)
==5526==by 0x67E83A8:
SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence
const&, com::sun::star::uno::Reference
const&) (frmload.cxx:611)


Ps : this file need few hours on my computer to be opened with LibO +
Valgrind and have bad results, this is the only usable result I've got.

Best regards

-- 
Arnaud Versini
From fa661be1e6ac23712d847720b116f53a6a9dc946 Mon Sep 17 00:00:00 2001
From: Arnaud Versini 
Date: Sun, 18 Mar 2012 10:20:37 +0100
Subject: [PATCH] Use ptr_vector instead of SV_DECL_PTRARR_DEL for
 WW8MergeGroups

---
 sw/source/filter/ww8/ww8par2.cxx |   59 --
 1 files changed, 25 insertions(+), 34 deletions(-)

diff --git a/sw/source/filter/ww8/ww8par2.cxx b/sw/source/filter/ww8/ww8par2.cxx
index b78030c..84fcfc5 100644
--- a/sw/source/filter/ww8/ww8par2.cxx
+++ b/sw/source/filter/ww8/ww8par2.cxx
@@ -97,8 +97,7 @@ public:
 
 typedef WW8SelBoxInfo* WW8SelBoxInfoPtr;
 
-SV_DECL_PTRARR_DEL(WW8MergeGroups, WW8SelBoxInfoPtr, 16)
-SV_IMPL_PTRARR(WW8MergeGroups, WW8SelBoxInfoPtr)
+typedef boost::ptr_vector WW8MergeGroups;
 
 struct WW8TabBandDesc
 {
@@ -186,7 +185,7 @@ class WW8TabDesc
 SwTableBoxes* pTabBoxes;// Boxen-Array in akt. Zeile
 SwTableBox* pTabBox;// akt. Zelle
 
-WW8MergeGroups* pMergeGroups;   // Listen aller zu verknuepfenden Zellen
+WW8MergeGroups aMergeGroups;   // Listen aller zu verknuepfenden Zellen
 
 WW8_TCell* pAktWWCell;
 
@@ -224,7 +223,7 @@ class WW8TabDesc
 void InsertCells( short nIns );
 void AdjustNewBand();
 
-// durchsucht pMergeGroups, meldet Index der ersten, passenden Gruppe bzw.
+// durchsucht aMergeGroups, meldet Index der ersten, passenden Gruppe bzw.
 // -1 Details siehe bei der Implementierung
 bool FindMergeGroup(short nX1, short nWidth, bool bExact, short& nMGrIdx);
 
@@ -1786,7 +1785,6 @@ WW8TabDesc::WW8TabDesc(SwWW8ImplReader* pIoClass, WW8_CP nStartCp) :
 pTabLine(0),
 pTabBoxes(0),
 pTabBox(0),
-pMergeGroups(0),
 pAktWWCell(0),
 nRows(0),
 nDefaultSwCols(0),
@@ -2112,7 +2110,6 @@ WW8TabDesc::~WW8TabDesc()
 }
 
 delete pParentPos;
-delete pMergeGroups;
 }
 
 void WW8TabDesc::CalcDefaults()
@@ -2630,11 +2627,6 @@ void WW8TabDesc::MergeCells()
 short nX1= pActBand->nCenter[ i ];
 short nWidth = pActBand->nWidth[ i ];
 
-// 0. falls noetig das Array fuer die Merge-Gruppen
-// anlegen
-if( !pMergeGroups )
-pMergeGroups = new WW8MergeGroups;
-
 // 2. aktuelle Merge-Gruppe anlegen
 pActMGroup = new WW8SelBoxInfo( nX1, nWidth );
 
@@ -2662,11 +2654,11 @@ void WW8TabDesc::MergeCells()
 while ( FindMergeGroup( nX1, pActMGroup->nGroupWidth,
 false, nMGrIdx ) )

Cppcheck reports "Uninitialized variable bIsRow" in formulaparser.cxx

[julien2412]

Hello,

Cppcheck reports this :
[source/filter/oox/formulaparser.cxx:2611]: (error) Uninitialized variable:
bIsRow
Here are the lines :
   2608 bool BiffFormulaParserImpl::readNlrSAddrAddData( BiffNlr& orNlr,
BiffInputStream& rStrm, bool bRow )
   2609 {
   2610 bool bIsRow;
   2611 return readNlrSRangeAddData( orNlr, bIsRow, rStrm ) && (bIsRow
== bRow);
   2612 }

Now the function called is just the lines after :
bool BiffFormulaParserImpl::readNlrSRangeAddData( BiffNlr& orNlr, bool&
orbIsRow, BiffInputStream& rStrm )
Ok, so orbIsRow must be initialized on this function. The pb is it isn't
always the case.

Moreover "readNlrSRangeAddData" is called by  2 functions :
- BiffFormulaParserImpl::importNlrSRangeToken
- BiffFormulaParserImpl::readNlrSAddrAddData

Now the question, should the boolean variables be initialized by the 2
calling functions, if yes at which value ?
Or should there be a default value (which one ?) on readNlrSRangeAddData ?

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-reports-Uninitialized-variable-bIsRow-in-formulaparser-cxx-tp3836234p3836234.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

LibreOffice - GSoC 2012

[Jayamal De Vas Gunawardhana]

Hi Folks,

I'm a 3rd year undergraduate of University of Moratuwa. While going through
the GSoS 2010 projects list I saw the project "Use your Smart Phone to
remote-control slideshow", LibreOffice project. I'm interested in Android
based development. Is there anyway to get further information on this
project.?

Thanks in advance.

-- 
*A.P.C.J. De Vas Gunawardhana.
Department of Computer Science and Engineering.
Faculty of Engineering
University of Moratuwa.*
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Cppcheck reports "Same expression on both sides of '=='" on dpitemdata.cxx

[julien2412]

Hello,

Just to make notice that Cppcheck reports "Same expression on both sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the lines :

199 bool ScDPItemData::IsCaseInsEqual(const ScDPItemData& r) const
200 {
201 if (meType != r.meType)
202 return false;
203 
204 switch (meType)
205 {
206 case Value:
207 case RangeStart:
208 return rtl::math::approxEqual(mfValue, r.mfValue);
209 case GroupValue:
210 return maGroupValue.mnGroupType ==
r.maGroupValue.mnGroupType &&
211 maGroupValue.mnValue == r.maGroupValue.mnValue;
212 default:
213 ;
214 }
215 
216 if (mbStringInterned && r.mbStringInterned)
217 return mpString == mpString;  < HERE
218 
219 return ScGlobal::GetpTransliteration()->isEqual(GetString(),
r.GetString());
220 }

It's the commit f81d15c3bab32938b5b475e16ae2a746a7a32ea9 (17/03/2012).

Julien.

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-reports-Same-expression-on-both-sides-of-on-dpitemdata-cxx-tp3836145p3836145.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Specifying a dependency with build?

[Lubos Lunak]

 Hello,

 what is the way to specify with gbuild that a target has another target as a 
dependency? I assume the tinderbox build failure at [1] was caused by a race 
condition, where sal_osl_module requires built Module_DLL in order to work, 
but didn't get lucky in this specific case.

[1] 
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1332055201.31263#14239

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice