Re: HttpClient -> HttpComponents

[Pierre-André Jacquod]

Hello,
used to progamm a bit, but due to lack of time, was not able to 
contribute with the speeding up of the tree...


But as it seems to be a very low level priority task, I will have a try.
>> " The Commons HttpClient project is now end of life, and is no

to remove at least this dependency.

> it's probably a waste of time since the only thing using it is
> the Wiki Publisher extension, which likely uses just basic features

> care about performance; it would be better to investigate whether

current JREs (version 6 as baseline) include some equivalent
functionality already to get rid of that external dependency instead


I will try first this path (pure Java rewrite), depsite I like better 
C++ :-)


I intend to remove its use class by class of httpclient. So in case of 
lack of time, a part is done and not lost.


Locally I have removed the use of httpclient.URI.

But I would need a hint: is there a documentfoundation / LO wiki where I 
can get access as _test_ in order to be able to check my changes?


thanks
Best regards
Pierre-André

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

Re: internal compiler error: in connect_traces, at dwarf2cfi.c:2676

[Pierre-André Jacquod]

Hello,
works fine by me. Did you try with another compiler / compiler version ?
I have
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
and last commit in master being:

d8dedc775cedf0e9daf9284bc7e3a0331ccd2963
EMF+: Integer coordinate values are signed.

regards
Pierre-André

On 12/28/2013 10:52 AM, mcmurchy1917-libreoff...@yahoo.co.uk wrote:

Quite early on in compilling LO I get the following error. Any suggestions on
how to resolve. It seems to suggest it's a problem with gcc not with LO.


/usr/bin/make -j 2 -rs -f /home/libreoffice/Downloads/core/Makefile.gbuild \

  \
  \
  \

 all

[build DEP] LNK:Library/libbasegfxlo.so
[build DEP] LNK:Library/libucbhelper.so
[build LNK] Library/libucbhelper.so
[build CXX] basegfx/source/polygon/b2dsvgpolypolygon.cxx
[build CXX] basegfx/source/polygon/b3dpolygontools.cxx
[build CXX] basegfx/source/polygon/b3dpolypolygon.cxx
/home/libreoffice/Downloads/core/basegfx/source/polygon/b2dsvgpolypolygon.cx
x: In function 'rtl::OUString basegfx::tools::exportToSvgD(const
basegfx::B2DPolyPolygon&, bool, bool, bool)':
/home/libreoffice/Downloads/core/basegfx/source/polygon/b2dsvgpolypolygon.c
xx:935:9: internal compiler error: in connect_traces, at dwarf2cfi.c:2676>
  }
  ^

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: ***
[/home/libreoffice/Downloads/core/workdir/CxxObject/basegfx/source/polygon/
b2dsvgpolypolygon.o] Error 1 make[1]: *** Waiting for unfinished jobs
make: *** [build] Error 2



Alex
___
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

Re: Beginner

[Pierre-André Jacquod]

Hello,
if you want to contribute with coding, I would suggest you:
- first (try to) build LibreOffice, depend on OS it can be tricky, but 
less than it used to be. This implies to download the source code, 
resolve dependencies and use the compiler
- if not yet, get familiar with git (some basic commands are needed) and 
with gerrit


once done, to get more familiar, try to solve an easy hack or solve a 
bug that you can reproduce. But I would recommend solve easy hacks, this 
would avoid starting in some too deep part of the code.


A good starting point is : https://wiki.documentfoundation.org/Development

Else on debugging, even if not solving, already isolating the exact 
point of the problem and the reason is already of big help and a good 
point to get infos/ advice of more experienced developers.


Best regards

On 12/23/2013 06:54 PM, prabhdeep singh wrote:

I want to start contributing to the open source community, but I do not
where to begin.
Your community's cause seems great!
So I would love to start but I am absolutely clueless as to where to begin.
I have a background in C++ and algorithmic operations.
Any help would be appreciated!


___
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

Re: Cppunit-1.13.0 released

[Pierre-André Jacquod]

hello,

git clone git://anongit.freedesktop.org/git/libreoffice/cppunit/
or
http://cgit.freedesktop.org/libreoffice/cppunit/

regards

On 07/07/2012 09:40 AM, Andreas Radke wrote:

Am Sat, 7 Jul 2012 04:19:39 +0200
schrieb Markus Mohrhard :


Hey,

after we have no longer any build issues with cppunit I have now
officially tagged the 1.13.0 release of cppunit. I would like to thank
everybody who helped during this release.


Have you forked the original project? I can't find the new release in
the projects page at
http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page
or http://sourceforge.net/projects/cppunit/

-Andy
ArchLinux
___
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

Re: Cppunit-1.13.0 released

[Pierre-André Jacquod]

hello,
updated :-)

http://en.wikipedia.org/wiki/CppUnit
regards

On 07/07/2012 04:19 AM, Markus Mohrhard wrote:

Hey,

after we have no longer any build issues with cppunit I have now
officially tagged the 1.13.0 release of cppunit. I would like to thank
everybody who helped during this release.

The changes against the 1.12.1 release are:

- improved windows build experience (VisualStudio project files for
2005 to 2010).
- warning free code
- no auto_ptr in a header any more
- some old bugs fixed (sf#2185407, sf#2186611, sf#3123759, sf#2983798,
rhbz#641350, fdo#51317)

All other changes can be seen in the NEWS file and at
http://cgit.freedesktop.org/libreoffice/cppunit/log/

Please spread the news about our first cppunit release and encourage
people to provide bug report, patches and documentation.

Regards,
Markus
___
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

Re: bug 49610 in impress: suspicious commit found, but help needed

[Pierre-André Jacquod]

Hello,

I locally reverted
bdfbbb33a491f3ce34375de14ba33436b04

> - sadly the change mixes a lot of reformatting with that fix. Hard
> to tell if that is now causing some ripple effects. :/

I can confirm this is the origin of the problem. The generated bug is 
very nasty (creates data loss) and the fix has to / should be in 3.6 as 
well as in 3.5.5


I also have to say honestly that fixing this patch is beyond my 
knowledge of LibO code in this area. So if you say OK, I will push my 
revert to master. This is not the most polite way of fixing it. 
destroying your correction, but the one that fit to my knowledge there.


Or have you time to investigate it and fix it ? Sorry, this sounds not 
very constructive, but in this period I do not have a lot of free time, 
so I can not offer more.


Tack
regards
Pierre-André


On 06/20/2012 11:10 PM, Thorsten Behrens wrote:

Pierre-André Jacquod wrote:

As I just do not understand what it is about here, (neither the goal
of the change nor the actual content), could you have a look about
it? I guess it will be the quickest way.


Hi Pierre-André,

well the goal was to decouple live cycles of Outliner and ViewShell

Cheers,

-- Thorsten



___
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

Re: [Libreoffice] What is bibisect? And what is it doing in my office?

[Pierre-André Jacquod]

Hi,
just to say thanks for bibisect
Impressive example with fdo49610 to find the problematic commit.

Regards
Pierre-André

On 12/09/2011 02:59 PM, Bjoern Michaelsen wrote:

Hi all,



So I hope with this, we make regression finding some more fun and allow us --
QA and developers together -- to stabilize this release more quickly that ever
before.

Bjoern

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

Re: [ANN] Please use Gerrit from now on for Patch Review

[Pierre-André Jacquod]

Hello,
well as free time contributor with commit access to current repository, 
I followed this gerrit story. So not kind of surprise, but yeah, until 
THIS mail and posts, was me very unclear what it would mean.


To say it, first I had a lot of doubt. Reading mails, entry in the wiki, 
looking the web ans thinking, I now have the feeling this could be a 
good move.


Just to say, I basically just really do not like the fact of having to 
use openId, would prefer to have an account at fd.o. I did it really for 
the LibO, a kind of forced to. And NO, I do NOT have any google, flickr, 
facebook or other account. Do not trust them enough to put my data 
there, so to use them as authentication But no choice (!) I kind of 
understood. [+1 for / to Lionel thread]


I - sorry - do not want to read a lot gerrit documentation, I am here 
already in my free time. So I raise some questions that are not clear 
for me, that I did not saw in the wiki, based on my previous 
experiences. Here some points:


[WORKFLOW]
1. I have been beaten back by tinderbox (Mac OS X hurt me well), fixing 
some stupid point of my commits run after run. So would this workflow be 
supported :

some patch done
I push to gerrit and let tinderbox run. In case of success I get ? a +1 
of each tinderbox ? How do I know it passes with success.
Once tinderbox is successful, since my change is small or I am confident 
with, I put a +2 to my patch, which means this will insert automatically 
it to master. So I will be able to positive review my own patch ?


2. If I have several patches, that need to be together, how should I 
proceed with pushing them together to gerrit ? (If I want to have three 
patches in the same review ID from gerrit) ?


[ADMIN]
1. I followed the asked process of setting up an account, etc.. mailed 
to Norbert so he can match my fd.o account to gerrit. Well, how may I 
now see that I actually have / will have commit access to gerrit repo ?


2. When my ssh key expires, it is enough to just change it into my 
gerrit account ?


3. May be a stupid remark, but why do not use this way (opening gerrit 
account ) then to ask for license stuff ? You would have to ack to be 
able to open account, or to load patches. This would ease, ensure the 
process towards this goal ?


Thanks & Regards
Pierre-André

On 06/18/2012 12:09 PM, Bjoern Michaelsen wrote:


Hi all,

with:

  http://sweetshark.livejournal.com/13298.html

gerrit is documented and ready to go. Please use it for code review as much as
possible now as it simplifies things a lot over manual patch fiddling on
mailing lists. I will update the EasyHacks to point to gerrit instead in the
next days.
The last remaining step will be making the repo at gerrit the reference (and
the one at freedesktop a read-only mirror). I assume that to be prepared and
done until mid-July(*).

From that point on, we will have a lot of opportunity to improve our tinderbox

testing and reporting, making life easier and better for everyone working on
the codebase.

Best,

Bjoern

(*) Along with the "other" repos.
___
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

bug 49610 in impress: suspicious commit found, but help needed

[Pierre-André Jacquod]

hello,
this bug is a bad regression. Following with debugger, I had as suspect 
the function void Outliner::ProvideNextTextObject (void) line 979 in 
sd/source/ui/view/Outliner.cxx (or something called late from this) as 
main suspect.


After bibisect from QA  the commit

bdfbbb33a491f3ce34375de14ba33436b04
slidesorter1: #i116014# Outliner holds ViewShell as weak_ptr.
* found as LGPLv3-only fix at svn rev 1172131 
(http://svn.apache.org/viewvc?view=revision&revision=1172131)



touch the suspected function, within the commit frame between last good 
and first bad binaries.


As I just do not understand what it is about here, (neither the goal of 
the change nor the actual content), could you have a look about it? I 
guess it will be the quickest way.


Beware: currently this commit is just a suspect, since I need more than 
4 hours to compile (I am on linux, yeah, but with my hardware...) I am 
still compiling the checkout to try & test.


If / when I get more info (means I have compiled it), I will update to 
confirm (or not) my suspect.


Thanks and regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: --enable-debug vs --enable-symbols (Re: [Libreoffice-commits] .: 12 commits - config_host.mk.in configure.in filter/source oox/source sal/inc sc/source solenv/gbuild toolkit/source xmlhelp/source)

[Pierre-André Jacquod]

Hello,

On 05/20/2012 11:24 PM, Norbert Thiebaud wrote:

On Wed, May 16, 2012 at 11:30 PM, Pierre-André Jacquod
  wrote:

expecting to get symbols without optimization, not wanting all asserts
outputs.


If you are intending to debug why wouldn't you want the misnamed
'assert output' ?
Better said, I do not care of them / are not useful: I try to solve some 
bugzilla points and it happens I have not yet have seen one caught by an 
assert :- )


Hence the minimum is the best for me. But yeah, I admit I most probably 
did not get the power of all this stuff.


Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: --enable-debug vs --enable-symbols (Re: [Libreoffice-commits] .: 12 commits - config_host.mk.in configure.in filter/source oox/source sal/inc sc/source solenv/gbuild toolkit/source xmlhelp/source)

[Pierre-André Jacquod]

hello,

On 05/16/2012 04:07 PM, Lubos Lunak wrote:


 If somebody does
a developer build, there are not many good reasons why -O2 should be used -
it takes noticably more time and it makes debugging miserable. I can't think
of anything else than final builds and profiling as a good non-corner-case
reason for -O2.



At least I understand why I always got debug builds with optimization, 
which does not ease the use of debugger... and why it takes so long to 
build.


As occasional developer, I do not want to dig to deep in build options - 
that is also not my interest. So with --enable-symbols, I was really 
expecting to get symbols without optimization, not wanting all asserts 
outputs.


Could it not stay like that? Or how do you obtain this effect (symbols, 
without optimization, without all asserts output?) I really do not want 
to take time to search for such thinks, hacking LO is already during my 
free time.

Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH] Re: input for fdo#45779 from a basegfx knowledgeable person needed

[Pierre-André Jacquod]

Hello,

On 05/03/2012 11:30 AM, Thorsten Behrens wrote:

So what I suggest is a more defensive fix (or some larger review
across the code is in order): make GetLineArrow() return the
B2DPolyPolygon right away, and have *that one* be empty (i.e. not a


Since I do not intend to become a specialist of this kind of elements, I 
choose your more defensive proposition.

So here the patch...
Thanks for a review and an ack before I push it.


Regards
Pierre-André
>From b77f2a21d222607edff535d3a069b8c30d4d2664 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Thu, 17 May 2012 17:51:33 +0200
Subject: [PATCH] fdo#45779 avoiding creation of inconsistent B2DPolygon

this avoid the root cause of this bug, avoiding creating a
B2DPlygon which contains no points.

It seems the code relies somehow on an null B2DPolyPolygon, hence the
change done here. Better would be to have time to look how to remove
this fact. But currently it seems the code relies on  a
rSet.Put( XLineStartItem( aArrowName, aPolyPoly) where aPolyPoly is
not defined in certain cases.

Change-Id: I61b75d925090d1c9a0da96ce1a6eea50a2d60e5a
---
 filter/source/msfilter/msdffimp.cxx |   29 +++--
 1 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/filter/source/msfilter/msdffimp.cxx b/filter/source/msfilter/msdffimp.cxx
index 80785fa..3d9efa7 100644
--- a/filter/source/msfilter/msdffimp.cxx
+++ b/filter/source/msfilter/msdffimp.cxx
@@ -1099,12 +1099,13 @@ void SvxMSDffManager::SolveSolver( const SvxMSDffSolverContainer& rSolver )
 
 
 
-static basegfx::B2DPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_LineEnd eLineEnd,
+static basegfx::B2DPolyPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_LineEnd eLineEnd,
 const MSO_LineEndWidth eLineWidth, const MSO_LineEndLength eLineLenght,
 sal_Int32& rnArrowWidth, sal_Bool& rbArrowCenter,
 rtl::OUString& rsArrowName, sal_Bool bScaleArrow )
 {
-basegfx::B2DPolygon aRetval;
+basegfx::B2DPolyPolygon aRetPolyPoly;
+
 double  fLineWidth = nLineWidth < 70 ? 70.0 : nLineWidth;
 double  fLenghtMul, fWidthMul;
 sal_Int32   nLineNumber;
@@ -1140,7 +1141,7 @@ static basegfx::B2DPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_L
 aTriangle.append(basegfx::B2DPoint( fWidthMul * fLineWidth, fLenghtMul * fLineWidth ));
 aTriangle.append(basegfx::B2DPoint( 0.0, fLenghtMul * fLineWidth ));
 aTriangle.setClosed(true);
-aRetval = aTriangle;
+aRetPolyPoly = basegfx::B2DPolyPolygon(aTriangle);
 aArrowName.appendAscii(RTL_CONSTASCII_STRINGPARAM("msArrowEnd "));
 }
 break;
@@ -1169,7 +1170,7 @@ static basegfx::B2DPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_L
 aTriangle.append(basegfx::B2DPoint( fWidthMul * fLineWidth * 0.15, fLenghtMul * fLineWidth ));
 aTriangle.append(basegfx::B2DPoint( 0.0, fLenghtMul * fLineWidth * 0.91 ));
 aTriangle.setClosed(true);
-aRetval = aTriangle;
+aRetPolyPoly = basegfx::B2DPolyPolygon(aTriangle);
 aArrowName.appendAscii(RTL_CONSTASCII_STRINGPARAM("msArrowOpenEnd "));
 }
 break;
@@ -1181,7 +1182,7 @@ static basegfx::B2DPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_L
 aTriangle.append(basegfx::B2DPoint( fWidthMul * fLineWidth * 0.50 , fLenghtMul * fLineWidth * 0.60 ));
 aTriangle.append(basegfx::B2DPoint( 0.0, fLenghtMul * fLineWidth ));
 aTriangle.setClosed(true);
-aRetval = aTriangle;
+aRetPolyPoly = basegfx::B2DPolyPolygon(aTriangle);
 aArrowName.appendAscii(RTL_CONSTASCII_STRINGPARAM("msArrowStealthEnd "));
 }
 break;
@@ -1193,16 +1194,16 @@ static basegfx::B2DPolygon GetLineArrow( const sal_Int32 nLineWidth, const MSO_L
 aTriangle.append(basegfx::B2DPoint( fWidthMul * fLineWidth * 0.50 , fLenghtMul * fLineWidth ));
 aTriangle.append(basegfx::B2DPoint( 0.0, fLenghtMul * fLineWidth * 0.50 ));
 aTriangle.setClosed(true);
-aRetval = aTriangle;
+aRetPolyPoly = basegfx::B2DPolyPolygon(aTriangle);
 rbArrowCenter = sal_True;
 aArrowName.appendAscii(RTL_CONSTASCII_STRINGPARAM("msArrowDiamondEnd "));
 }
 break;
 case mso_lineArrowOvalEnd :
 {
-aRetval = XPolygon( Point( (sal_Int32)( fWidthMul * fLineWidth * 0.50 ), 0 ),
+aRetPolyPoly = basegfx::B2DPolyPolygon( XPolygon( Point( (sal_Int32)( fWidthMul * fLineWidth * 0.50 ), 0 ),
 (sal_Int32)( fWidthMul * fLineWidth * 0.50 ),
-(sal_Int32)( fLenghtMul * fLineWidth * 0.50 ), 0, 3600 ).getB2DPolygon();
+(sal_

some license statement

[Pierre-André Jacquod]

Hello,
just to confirm that all of my past & future contributions to 
LibreOffice may be licensed under the MPL/LGPLv3+ dual license.


Best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] Re: input for fdo#45779 from a basegfx knowledgeable person needed

[Pierre-André Jacquod]

Hello,
back again after a while.


On 02/15/2012 11:30 AM, Thorsten Behrens wrote:

Fixed with d37abad97d72bae0fd0269de12e94c7a7d3fd7e1 - but, if you
like, would be cool to chase down why in the first place the ppt
import creates polygons with empty sub-paths, that looks like a
worthwhile optimization - code is around
filter/source/msfilter/msdffimp.cxx probably.


It happens that basegfx::GetLineArrow(...) (also defined within 
msdffimp.cxx, line 1102) does not create a valid polygon when eLineEnd 
has the value mso_lineNoEnd...

In the switch(eLineEnd), this goes to
>  default: break;
without creating any polygon, letting the return value undefined.

So I propose to skip the creation these incorrect polygons if eLineEnd 
has the value mso_lineNoEnd. But since I do not understand well the 
import / translation from msformat, I may also have missed a big point. 
Hence thanks for reviewing this patch, before I push it.


I hope it helps.

Regards
Pierre-André
>From ec4bf50361f3d2c75e2de20fdb1ddebddba8d406 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 28 Apr 2012 18:57:02 +0200
Subject: [PATCH] impress ms import filter avoid b2dpolygon with 0 b2dpoints

when the lineEnd value is mso_lineNoEnd, the created polygon was
incomplete and with no points, then disabling it.
---
 filter/source/msfilter/msdffimp.cxx |   44 +++---
 1 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/filter/source/msfilter/msdffimp.cxx b/filter/source/msfilter/msdffimp.cxx
index 80785fa..f208dd9 100644
--- a/filter/source/msfilter/msdffimp.cxx
+++ b/filter/source/msfilter/msdffimp.cxx
@@ -1329,17 +1329,20 @@ void DffPropertyReader::ApplyLineAttributes( SfxItemSet& rSet, const MSO_SPT eSh
 if ( IsProperty( DFF_Prop_lineStartArrowhead ) )
 {
 MSO_LineEnd eLineEnd = (MSO_LineEnd)GetPropertyValue( DFF_Prop_lineStartArrowhead );
-MSO_LineEndWidtheWidth = (MSO_LineEndWidth)GetPropertyValue( DFF_Prop_lineStartArrowWidth, mso_lineMediumWidthArrow );
-MSO_LineEndLength   eLenght = (MSO_LineEndLength)GetPropertyValue( DFF_Prop_lineStartArrowLength, mso_lineMediumLenArrow );
 
-sal_Int32   nArrowWidth;
-sal_BoolbArrowCenter;
-rtl::OUString aArrowName;
-basegfx::B2DPolygon aPoly(GetLineArrow( nLineWidth, eLineEnd, eWidth, eLenght, nArrowWidth, bArrowCenter, aArrowName, bScaleArrows ));
+if ( eLineEnd != mso_lineNoEnd )
+{
+MSO_LineEndWidtheWidth = (MSO_LineEndWidth)GetPropertyValue( DFF_Prop_lineStartArrowWidth, mso_lineMediumWidthArrow );
+MSO_LineEndLength   eLenght = (MSO_LineEndLength)GetPropertyValue( DFF_Prop_lineStartArrowLength, mso_lineMediumLenArrow );
+sal_Int32   nArrowWidth;
+sal_BoolbArrowCenter;
+rtl::OUString aArrowName;
+basegfx::B2DPolygon aPoly(GetLineArrow( nLineWidth, eLineEnd, eWidth, eLenght, nArrowWidth, bArrowCenter, aArrowName, bScaleArrows ));
 
-rSet.Put( XLineStartWidthItem( nArrowWidth ) );
-rSet.Put( XLineStartItem( aArrowName, basegfx::B2DPolyPolygon(aPoly) ) );
-rSet.Put( XLineStartCenterItem( bArrowCenter ) );
+rSet.Put( XLineStartWidthItem( nArrowWidth ) );
+rSet.Put( XLineStartItem( aArrowName, basegfx::B2DPolyPolygon(aPoly) ) );
+rSet.Put( XLineStartCenterItem( bArrowCenter ) );
+}
 }
 /
 // LineEnd //
@@ -1347,17 +1350,20 @@ void DffPropertyReader::ApplyLineAttributes( SfxItemSet& rSet, const MSO_SPT eSh
 if ( IsProperty( DFF_Prop_lineEndArrowhead ) )
 {
 MSO_LineEnd eLineEnd = (MSO_LineEnd)GetPropertyValue( DFF_Prop_lineEndArrowhead );
-MSO_LineEndWidtheWidth = (MSO_LineEndWidth)GetPropertyValue( DFF_Prop_lineEndArrowWidth, mso_lineMediumWidthArrow );
-MSO_LineEndLength   eLenght = (MSO_LineEndLength)GetPropertyValue( DFF_Prop_lineEndArrowLength, mso_lineMediumLenArrow );
+if ( eLineEnd != mso_lineNoEnd)
+{
+MSO_LineEndWidtheWidth = (MSO_LineEndWidth)GetPropertyValue( DFF_Prop_lineEndArrowWidth, mso_lineMediumWidthArrow );
+MSO_LineEndLength   eLenght = (MSO_LineEndLength)GetPropertyValue( DFF_Prop_lineEndArrowLength, mso_lineMediumLenArrow );
 
-sal_Int32   nArrowWidth;
-sal_BoolbArrowCenter;
-rtl::OUString aArrowName;
-basegfx::B2DPolygon aPoly(GetLineArrow( nLineWidth, eLineEnd, eWidth, eLenght, nArrowWidth, bArrowCenter, aArrowName, bScaleArrows ));
+sal_Int32   nArrowWidth;
+sal_BoolbAr

Re: input for fdo#45779 from a basegfx knowledgeable person needed

[Pierre-André Jacquod]

hello,

Fixed with d37abad97d72bae0fd0269de12e94c7a7d3fd7e1 - but, if you

thanks


import creates polygons with empty sub-paths, that looks like a
worthwhile optimization - code is around
filter/source/msfilter/msdffimp.cxx probably.


as soon as I have more spare time, I will have a try.
Regards
Pierre-André

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

input for fdo#45779 from a basegfx knowledgeable person needed

[Pierre-André Jacquod]

hello,
I have quickly investigated the crash in fdo#45779 when saving an 
impress document.


The reason of the crash is in basegfx/inc/basegfx/point/b2dpoint.hxx 
(line 82) where this is called:


2DPoint::B2DPoint (this=0xbfffc850, rPoint=...)
  :   B2DTuple(rPoint)
(from back-trace)

It turns out that in this case, rPoint is 0x0, the null pointer.
and B2DTuple does not support it

B2DTuple(const B2DTuple& rTup)
:   mfX( rTup.mfX ),
mfY( rTup.mfY )
{}

Here you dereference the null pointer, which crash.

Ok, the basic attitude would be to let B2DTuple be Null-pointer 
consistent: (checking that rTup is not NULL), but is it really a good idea?


What is a NULL B2DTuple ?

Or should the caller (this is called due to 
basegfx/source/polygon/b2dpolygon.cxx:1257) take care of the case, 
returning either the value, ... or NULL ?


B2DPoint B2DPolygon::getB2DPoint(sal_uInt32 nIndex) const
{
OSL_ENSURE(nIndex < mpPolygon->count(), "B2DPolygon a
return mpPolygon->getPoint(nIndex);
}


Or should I look higher in the hierarchy, saying that a NULL point in a 
B2DPolygon has nothing to do and disallow it ?


As far as I could seee, this polygon had 4 elements / points, all with 
NULL data at the time of the crash :-/


What would be the right (and most meaningfull) approach ?

Thanks & regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [ANN] Referencing bugs in commits

[Pierre-André Jacquod]

hello,


The bug reference has to have fdo#ABCDE form (where ABCDE is the bug
number), and has to be at the first line of the commit (it does not
matter where on that line).


Sorry, one point is for me not clear:

by the first line, do you mean "title line" or would it works also as 
first line of the comment (hence not being into the title) ?


Thanks
Pierre-André

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

Re: [Libreoffice] bug 36874 (label printing) further improvement?

[Pierre-André Jacquod]

Hello,

Just to mix in the middle: from this and a previous mail from you:


 >> It would be much better if the label-definitions contain all
dimensions, i.e.


yes

> My calculation is based on the assumption (presumption?) that the
> page containing the labels is symmetrical, i.e. rotating the page
> 180 degrees is not a problem, left margine equals right margin and
> top margin equals bottom margin.

some labels paper that I bought last year (I guess of too bad quality) 
were not symmetric


But anyway, the change is already very good.
Thanks
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)

[Pierre-André Jacquod]

Hi Eicke,


The second one:
0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch


For consistency it makes sense to also shrink the area, as
re-initializing the filter area with only one cell or one row selected

.

erroneously included. Please go ahead with this one.


OK


Please check that a defined data base range did not change behavior with
your previous changes.
I have look at the code where GetDataArea is called. The only places 
where a behaviour change could happen are in function GetDBData ( 
sc/source/ui/docshell/docsh5.cxx )
if bOnlyDown is true. In this case, the area will be shrink - if needed 
-  only for the number of rows. Before, all 4 sides (top, right, left 
and bottom) could be shrink. But this change exists only if we shrink. 
For expanding, the behaviour was already ensured as described (bOnlyDown 
= true would have expanded only down, not the other directions).


This now makes the behaviour symmetric between shrinking / expanding the 
area. Based on flags and description, the former behaviour was buggy, 
but maybe something has been build depending of it. Despite knowing what 
is changed, I was not able to produce a way of using it that seemed to 
be problematic. I see you have worked on this function, maybe something 
will strike you immediately :- ).


So here the patch. If no one object, I will push it during my Christmas 
Holiday.


Best regards
Pierre-André

>From 994b2c2e5a760503f8e466ae8068cf1cc453a712 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Thu, 15 Dec 2011 19:29:17 +0100
Subject: [PATCH 1/2] fdo42286 better solution: extend and shrink end of row if needed

---
 sc/source/core/tool/dbdata.cxx |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/sc/source/core/tool/dbdata.cxx b/sc/source/core/tool/dbdata.cxx
index 3d60554..3cc4146 100644
--- a/sc/source/core/tool/dbdata.cxx
+++ b/sc/source/core/tool/dbdata.cxx
@@ -544,10 +544,8 @@ void ScDBData::UpdateReference(ScDocument* pDoc, UpdateRefMode eUpdateRefMode,
 void ScDBData::ExtendDataArea(ScDocument* pDoc)
 {
 // Extend the DB area to include data rows immediately below.
-SCCOL nCol1a = nStartCol, nCol2a = nEndCol;
-SCROW nRow1a = nStartRow, nRow2a = nEndRow;
-pDoc->GetDataArea(nTable, nCol1a, nRow1a, nCol2a, nRow2a, true, true);
-nEndRow = nRow2a;
+// or shrink it if all cells are empty
+pDoc->GetDataArea(nTable, nStartCol, nStartRow, nEndCol, nEndRow, false, true);
 }
 
 namespace {
-- 
1.7.3.4

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

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)

[Pierre-André Jacquod]

Hello,


To give you a background, this "extend range downward" functionality was

Thanks for your explanation.

Following the remark of Eicke, I ended up with 3 possible patches :-/ 
which all have small differences in behaviour. I have a favorite, but do 
not want to choose alone. Please push the one you think is the best for 
the filter drop-down.


The first one is my favorite:
0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch
it extends the area down. It takes into account the cells strictly below 
the already selected area. It never shrinks / shortens the selected 
area. This is the one that implement in my opinion the best the 
behaviour of adding data below already active area.


The second one:
0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch
has the same logic, except it allows to shrink the area, if cells are 
emptied. This the filter is allowed to extend, it could be seen as logic 
that it is also allowed to shrink.


The last one:
0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch
extend down, but also if data is added to the first cell bellow. so if 
you have something like (o means empty cell, x cell with data), initial 
filter only on B2:D3

o
oXXXo
oXXXo
X
and add the last X below right, the the last line will be included in 
the area and shown with "empty cells" selection. I do not like this, 
since it suddenly take into account a column which was not part of the 
initial filtered area.


Due to my job, I have not been very available last week, and it will be 
the same this week. (I will not be able to code / push until 9th). would 
be nice if this could be inserted before branching to 3.5.0


As prerequisite for working, the following commits are needed:

7359ad4fc772bc355905ef8b4a4a7b44dcfc1ebe
2e5023f974dd94dfeec0554ce07d0544f9ce7638
e42ee773ffc12e38d596ce2aa016f0849c4e5ac6

Regards
Pierre-André


0001-fdo42286-strict-use-of-GetDataArea-and-strict-extens.patch
Description: application/mbox


0001-fdo42286-extend-down-but-also-shrink-if-cells-are-em.patch
Description: application/mbox


0001-fdo42286-extend-down-even-if-last-row-empty-but-a-co.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area (2)

[Pierre-André Jacquod]

Hello,
sorry, I was sure there was more about it...but too early this morning, 
I could not sort out all points.



Now you also changed bOnlyDown=false to bOnlyDown=true, which leads to
not include newly appended columns of an area. Why?

by the way, this reflect the comment in

void ScDBData::ExtendDataArea(ScDocument* pDoc)
{
// Extend the DB area to include data rows immediately below.

which comment is from Kohei ( 9f9ff37f ) who toke this from a previous 
comment. Hence, the change would make the call be in line with the comment.


This is the original reason why I started to play with it and changed it 
like this, since comment and implementation were not coherent.


Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area

[Pierre-André Jacquod]

Hi Eike


Now you also changed bOnlyDown=false to bOnlyDown=true, which leads to
not include newly appended columns of an area.


half true: the condition is exactly that the newly appended column data 
touch by an angle the already defined area (like C3 to B2) and that all 
other cells below the area are empty.

All columns right/left of the area are filtered.


Why?
very bad reason: I did not really intended to commit this change yet. I 
wanted to ask you about it. But it seems I was too deeply thinking about 
it, I oversee my mixing. F**


less bad reason: If you activates the auto-filter, and append a column 
as mentioned above, you suddenly have columns filtered without "seeing" 
it, the drop-down at the top of the column not being present.


I will change it (due to point 1), except you oppose :- )


Grounded speculation: if user adds a column or row immediately adjacent
to a data area it is usually related to the already existing data and
she wants that to be included, maybe even doesn't know that earlier the
filter was setup using a selection.


A good point. On the other hand,this makes impossible to filter in the 
middle of data. But this case is very special.



Else, I have attached 3 patches for review touching this function:

* the first one make the flag onlyDown working also for shrinking... No 
reason that you can just extend down, but shrink on all direction? This 
seems to be more coherent with the flag activation.


* the second patch make the shrinking corresponding to the name of the 
function: GetDataArea: i.e. shrinks as long as the outer row/column is 
empty, and not just delete the last one since empty.


* the 3d one: just minor clean up: variable scope reduction and better 
documentation.


Thanks for all
best regards
Pierre-André
>From cfd04dda7e441ffa3dcc5a21b6b8f87cbfda05b0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Tue, 29 Nov 2011 09:10:26 +0100
Subject: [PATCH 3/3] reduce scope of var and better comment of function GetDataArea

---
 sc/source/core/data/table1.cxx |   40 +---
 1 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/sc/source/core/data/table1.cxx b/sc/source/core/data/table1.cxx
index ce2051b..5de641f 100644
--- a/sc/source/core/data/table1.cxx
+++ b/sc/source/core/data/table1.cxx
@@ -741,17 +741,19 @@ bool ScTable::GetDataStart( SCCOL& rStartCol, SCROW& rStartRow ) const
 void ScTable::GetDataArea( SCCOL& rStartCol, SCROW& rStartRow, SCCOL& rEndCol, SCROW& rEndRow,
bool bIncludeOld, bool bOnlyDown ) const
 {
-// bIncludeOld = true ensure that the returned area contains at least the initial area,
-//  independently of the case if this area has empty rows / columns at its borders
-// bOnlyDown = true means extend the inputed area only down, i.e increase only rEndRow
+// return the smallest area containing at least all contiguous cells having data. This area
+// is a square containing also empty cells. It may shrink or extend the area given as input
+// Flags as modifiers:
+//
+// bIncludeOld = true ensure that the returned area contains at least the initial area,
+//   independently of the emptniess of rows / columns (i.e. does not allow shrinking)
+// bOnlyDown = true means extend / shrink the inputed area only down, i.e modifiy only rEndRow
+
 bool bLeft = false;
 bool bRight  = false;
 bool bTop = false;
 bool bBottom = false;
-bool bChanged;
-bool bFound;
-SCCOL i;
-SCROW nTest;
+bool bChanged = false;
 
 do
 {
@@ -782,12 +784,12 @@ void ScTable::GetDataArea( SCCOL& rStartCol, SCROW& rStartRow, SCCOL& rEndCol, S
 
 if (rStartRow > 0)
 {
-nTest = rStartRow-1;
-bFound = false;
-for (i=rStartCol; i<=rEndCol && !bFound; i++)
+SCROW nTest = rStartRow-1;
+bool needExtend = false;
+for ( SCCOL i = rStartCol; i<=rEndCol && !needExtend; i++)
 if (aCol[i].HasDataAt(nTest))
-bFound = true;
-if (bFound)
+needExtend = true;
+if (needExtend)
 {
 --rStartRow;
 bChanged = true;
@@ -798,12 +800,12 @@ void ScTable::GetDataArea( SCCOL& rStartCol, SCROW& rStartRow, SCCOL& rEndCol, S
 
 if (rEndRow < MAXROW)
 {
-nTest = rEndRow+1;
-bFound = false;
-for (i=rStartCol; i<=rEndCol && !bFound; i++)
+SCROW nTest = rEndRow+1;
+bool needExtend = false;
+for ( SCCOL i = rStartCol; i<=rEndCol && !needExtend; i++)
 if (aCol[i].HasDataAt(nTest))
-bFound = true;
-if (bFound)
+needExtend = true;
+if (needExtend)
 {
  

Re: [Libreoffice] final and override

[Pierre-André Jacquod]

Hello,


However, given that override and final will only make it into GCC 4.7
(according to ), it


according to gcc.gnu.org too..

but since it seems that MSCV (according the same wiki) supports it / 
will support it, why not just wait a bit and then use it directly, 
setting a minimal compiler version ? This would allow a "cleaner" code, 
not having to take into account "before implementation" status. (would 
also be valid for other major features ) Most probably a too harsh 
approach ?

regards
Pierre-André

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

Re: [Libreoffice] [PATCH] fdo#42286, do not shrink the selected area

[Pierre-André Jacquod]

Hi,


BUT this is a workaround, to compensate the not so correct behaviour
of GetDataArea :-(


The behaviour in bINcludeOld = false seems me strange (ergh I think 
wrong but you told me to be cautious), since it removes from the "side" 
of the area that has not yet been extended above the last line / column, 
if empty.
The implementation seems to me flawed, since it does it even if no 
extension has been possible (e.g rEndRow = MAXROW), and suppress just 
ONE line, if empty. What about the "new" last one ? if also empty, we 
are exactly in the same situation as before, just a bit smaller. Hence 
it seems me that the original programmer (12 years ago) just assumed 
that only the last line / column could be empty, not e.g. the last 4 rows.



I wouldn't say it's wrong unless I checked the original intention behind
that code when GetDataArea() is called with bIncludeOld=false, maybe
it's just the call in ExtendDataArea() that should pass true instead?


Done, you're right.
Finally, changed the call of the flags and documented the flags' meaning.
If you could cherry-pick 88611e702a18d2 for 3.4.5, would be nice.
Many thanks


desired effect. Further some tests have shown me that the behaviour
(regarding area) is not the same, depending if the filter is
activated with Data->Filter->AutoFilter or Standard filter. I fear
some parts will need to be quite overhauled.


And the difference exactly is ...?


Visually: the standard filter adapts and shows the selected area at 
activation of the filter, the auto-filter does not reflect the fact that 
it will take into account a wider area. This area extension happens only 
when the drop-down button is activated and the list of possible value is 
calculated...  and the area extended.


More subtly, this leads to 2 different ranges stored within the file if 
you do

"select some area but not all data", activate standard filter , save

or  if you do  exactly the same  with same data / input except 
activating auto-filter instead of standard filter.


Out of subject: from a user perspective, I am not convinced from te fact 
that the filter is allowed to change an area that has been user-defined. 
No problem to auto-extend an area if auto-determined. But if a user 
takes the time to do the area, this should be "holly". But this point 
belongs to the user-interface list I guess...


Best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] fdo#42286, do not shrink the selected area

[Pierre-André Jacquod]

hello,
here attached an new patch (hopefully wiser) to solve the mentioned bug. 
This  ensure that the call to ExtendDataArea does as commented in the 
code sc/source/core/tool/dbdata.cxx :

// Extend the DB area to include data rows immediately below.
and does not shrink the original area... So having a smaller area after 
the function is clearly wrong.


If you agree, I will push it to master.

BUT this is a workaround, to compensate the not so correct behaviour of 
GetDataArea :-(


I did this patch in order to bring the correction in time for 3.5.0 & 
3.4.5, but I agree, that this is suppressing a symptom and not the root 
cause.


About the root cause: I am still studing the code of the both mentioned 
functions and their integration with filters and filtered areas. Before 
touching it, I would like to define what should be the desired effect. 
Further some tests have shown me that the behaviour (regarding area) is 
not the same, depending if the filter is activated with 
Data->Filter->AutoFilter or Standard filter. I fear some parts will need 
to be quite overhauled.


As said, won't be ready for 3.5, so first this short term solution.

Thanks toa all for having helped me so far.
Best regards
Pierre-André


0001-fdo-42286-do-not-shrink-the-filtered-area-when-calli.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] fdo 42286 in calc solved ?

[Pierre-André Jacquod]

Hello,
thanks for the answer


My solution: suppress this call...

is that, you've just removed a valid functionality.  I'm afraid I can't
push your change, since the line you wish to remove is there for a
reason.
which is ?? (not to argue, just to understand since I really tried to 
find a sense at this call before writing the mail. And did not found any 
and I have tested in different cases and did not noticed any side effect).


Ok for all what you say about auto-range I agree with it and I 
understood from the code that this is the intention. BUT where I do not 
see the rational :


this removed call i.e. the determination of the auto-range is called 
only (and each time) the drop-down button of the filter is clicked, just 
when building the drop-down list value. This path is NOT used on filter 
activation. This path is used each time you change the value by which 
the column is filtered, (in the drop down list) the auto-range is again 
calculated and changes.


In other words, it means, that each time you change the filtered value, 
the area which is under "filter control" changes: is this really the 
intended design ?


As user, I do not think that this is intuitive and awaited. I would 
await that the filter is working on the selected area and that changing 
the value active for filtering does not alter its working area.


(If I repeat, that's not because I think you are dumb, that's because I 
really do not know if I am able to express myself in an understandable 
way in English :-(


OK, that said, where did I missed the steps and fall one floor down ?


Also, your use case is a weird one.  Normally Calc users don't want to
filter out the bottom empty rows.
ergh, just a point of view :- ) And no, I see a lot of people doing 
this... and giving up. (btw I do not know the one who opened the ticket)


just a basic action (which is not weird):
cell A1: a, cell B1 b
cell A2 aa, cell B2 bb
select the whole sheet, activate standard filter
filter for value like aa in column a
.

and to have funnier results just play changing the filtered value, not 
forgiving to go regularly through the filter value (ALL)

cell A1: a, cell B1 b
cell A2 aa, cell B2 bb
select column A and B, active auto-filter (with header, that's nice)
filter for value aa in column A
filter for non empty in column B
filter for ALL in B
filter for ALL in A
filter for value aa in column A


I hope not to waste (too much of) your time. Just I am very rational and 
like to understand, Especially when I have the impression that this is 
against the (or my ?) logic.


Thanks
Best regards
Pierre-André

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

Re: [Libreoffice] [PATCH] fdo 42286 in calc solved ?

[Pierre-André Jacquod]

Hello,

Thanks for your hints. It took some times, but know I have clearly 
identified the problem , but I do not if my solution is right or could 
create more problems.


In short, the problem is that GetAreadData is called each time the 
filter determines its values, instead of using the current area. This 
does not have influence, as long as your selection area does not end 
with empties rows or empties columns.


But this behaviour produce a wrong result as soon as your filtered area 
ends with empties rows, and as special case, if you select all rows, 
since it decreases the area of 1 row if the last row is empty.


Basically this happens with the call of function ExtendDataArea. This 
originates from documen3.cxx, function GetFilterEntries line 1390 (the 
call itself is at line 1398). (more details below, if needed)


My solution: suppress this call...
I have tested it and it seems to work. I did not managed to find a case 
where something is broken with the filter..


But it seems me too simple.
Could you check this before I push it ?

If Ok, would you like then to approve it & cherry-pick it to 3.4.5 ?

Thanks & best regards
Pierre-André

ps: if what I did is right, I will then update the bug ticket

---

What happens?
As I understand after debugging and following the logic, each time the 
filter is activated (it is an auto-filter) it tries do determine the 
data range when it search for its value to show in the filter drop-down.


For that it searches the biggest contiguous area of data, as when 
applying the filter without selection.


Except the fact that here it goes wrong, since an area has already 
selected (either manually or stored as which contains and finish (important in this analysis) with several 
empty rows (columns would produce the same problem). And it tries to fit 
the Area with the GetAreaData algorithm, starting with a predefined 
area. The result: it does not extend it (next row is emtpy), but 
thinking he as extended the area of one row to far (this the last row 
int the area is empty), it reduce the selected area of one row.


And this produce the strange comportment described. (more detailed 
analysis below).


Each time the filter value is changed , the function 
ScTAble::GetAreaData (in  sc/source/core/data/table1.cxx, line 740 in my 
check-out) is called.
At the end of the called function, there is a check: if the last row is 
empty, then the Area is reduced by one, deacreasing its last row value 
by 1 (line 835/836)

if (!bFound)
--rEndRow;

This is obviously wrong, especially if you select e.g the 3 first 
columns (completely) and then apply auto-filter. Since empty lines *are* 
part of the selection... and not only the last one is empty. So each 
time I change the filter value, I reduce by 1 the last row number...



I see that the content.xml ends with some strange empty row

It is ill-formatted by the user ;-)  Cells in columns A:G down to the



However, strange are the spurious entries with
table:visibility="filter"


no, this is the result of this filter changes coupled with the order of 
"ALL" value filter or partial filters.


This also creates a mess with the storage of
>From 568c0635089964488a05043d7422eb40be15ccaf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Tue, 15 Nov 2011 20:55:53 +0100
Subject: [PATCH] fdo#42286 do not change selection area when determining filter values

Just use the current area, does not redetermine it in order to
find the list of values for drop-down of the filter.
---
 sc/source/core/data/documen3.cxx |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/sc/source/core/data/documen3.cxx b/sc/source/core/data/documen3.cxx
index 273af5f..14b0655 100644
--- a/sc/source/core/data/documen3.cxx
+++ b/sc/source/core/data/documen3.cxx
@@ -1395,7 +1395,6 @@ bool ScDocument::GetFilterEntries(
 ScDBData* pDBData = pDBCollection->GetDBAtCursor(nCol, nRow, nTab, false);  //!??
 if (pDBData)
 {
-pDBData->ExtendDataArea(this);
 SCTAB nAreaTab;
 SCCOL nStartCol;
 SCROW nStartRow;
-- 
1.7.3.4

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

Re: [Libreoffice] some hints needed for fdo 42286 in calc

[Pierre-André Jacquod]

hello,


and query information. The query is executed in ScDBDocFunc::Query and
related functions.


thanks I will look there & come back if needed


P.S. Do you know if this is a regression against 3.3? Then it might be


No 3.3 available to test (and a bit short of place on HD).

But happens on

LibreOffice 3.4.2
OOO340m1 (Build:1206)
(OpenSuse 11.4 distribution)

and on master, build by myself (also OpenSuse 3.4.2)

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] some hints needed for fdo 42286 in calc

[Pierre-André Jacquod]

hello,

I am trying to debug fdo 42286 in calc. It has to do with autofilter, 
where some empty lines (rows) are shown despite the filter criteria that 
is set. (and a strange filter behaviour).


As entry point, I found sc/.. tools/queryparam.cxx & dbdata.cxx but it 
seems that there all is Ok.


As I understand it, there the query is just "prepared" but I am not able 
to find the code where the actual calculation for displaying it is done. 
could someone hint me / give me a search criteria ?


Just an additional remark: "disassembling" the bug's attached file, I 
see that the content.xml ends with some strange empty row definitions... 
But this still does not justify to appear witin the filter in my 
opinion. Or does this indicates the file is ill formatted ? (sorry, I do 
not know the oasis spec)


table:number-rows-repeated="1048532">




table:visibility="filter">table:number-columns-repeated="1024"/>







table:visibility="filter">table:number-columns-repeated="1024"/>







table:number-rows-repeated="5">




etc all of this kind

thanks for a hint
regards

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

Re: [Libreoffice] master build fails in basegfx

[Pierre-André Jacquod]

hello,

On 10/09/2011 02:04 PM, Jean-Baptiste Faure wrote:
> Le 09/10/2011 09:18, Matúš Kukan a écrit :
>> On 9 October 2011 09:13, Jean-Baptiste Faure :

I try to build the master and I get an error in building basegfx.


git revert 49861a0246547554e285b4d14f049a28addd4ddc

But I can't reproduce. Feel free to revert.


reverting this commit make the build successful. But it is strange.


seems to break also different tinderboxes ( 
http://tinderbox.libreoffice.org/MASTER/status.html )



I probably did something wrong when I duplicated my master in bugfix.


or some parameters for autogen where not the same between your two dir, 
or not done a clean build (from scratch) after integrating it.


One of my commits (see  78b1cc1a08d71 ) also broke some tinderboxes, but 
I did not got the managed to reproduce locally the problem that concern 
you. (some --enable that I did not have, most probably)


regards
Pierre-André
ps: fixing better than reverting, if possible..:- )
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Declarations after statements

[Pierre-André Jacquod]

Hello,


Declarations after statements are possible only in C99. And MSVC does
not support C99 (refrain from bitching here, please).


sorry Tor, I was not enthusiasm, just systematic and from *xes world.
... and I am - almost - too young to know there was a C89 before...

If time allows, I will try during the dark winter days to compile with 
this strange outdated software called , kind of a black power as I 
heard, MSVC 2010 :-)


regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] master build fails in basegfx

[Pierre-André Jacquod]

hello,

On 10/09/2011 02:04 PM, Jean-Baptiste Faure wrote:

Le 09/10/2011 09:18, Matúš Kukan a écrit :

On 9 October 2011 09:13, Jean-Baptiste Faure :

I try to build the master and I get an error in building basegfx.


git revert 49861a0246547554e285b4d14f049a28addd4ddc

But I can't reproduce. Feel free to revert.


reverting this commit make the build successful. But it is strange.


seems to break also different tinderboxes (
http://tinderbox.libreoffice.org/MASTER/status.html )


I probably did something wrong when I duplicated my master in bugfix.


or some parameters for autogen where not the same between your two dir,
or not done a clean build (from scratch) after integrating it.

One of my commits (see  78b1cc1a08d71 ) also broke some tinderboxes, but
I did not got the managed to reproduce locally the problem that concern
you. (some --enable that I did not have, most probably)

regards
Pierre-André
ps: fixing better than reverting, if possible..:- )
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc

[Pierre-André Jacquod]

On 10/07/2011 03:51 PM, Norbert Thiebaud wrote:

2011/10/7 Marc-André Laverdière:

Wow, I really missed the 'big debate' :)

me too :- )


- I don't think we can expect developers to run a build before each
push,


Yes we absolutely can expect that. it is actually a bare minimum !
rebase, clean build Ok, rebase and build done on Linux, all ok. (with 
about 70 small patches of warning reduction)


Then

Push ...
read mails, deleted some recurrent Windows tinderboxes mails  - and read 
among others this one :- )



AND keep an eye on the tinderboxes. usually within 20 minutes
you should have the result of a tinderbox run with your pushed change
in it (except windows so far).


look at my trash, see that this time I got also tinderboxes mails from 
MacOSX... Looked at log (since I have read this mail), did not 
understand from a possible guilty commit why this should break MacOSX 
compilation, try a "best guess" revert and see a green rebuild.


And now fully convinced of the utility of tinderboxes, and of the need 
to take care of them in respect of other platforms that I do not have.


Just to thanks tinderboxes maintainers
Best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] dmake/win95: deprecated directory ?

[Pierre-André Jacquod]

Hello,

dmake is 3rd-party software,

thanks,

with "One git", not being familiar with all part of the code and the 
structure, not always easy to know what is LO and 3rd-party.


Should it not belongs to "external/" ? Or what is the semantic there ?

Or would it make sense to have at the top level a directory (like 
3rdparty) to put all these in - I guess zlib, lucene or m4 are the same 
kind of code ?)


Would be easier to understand the structure..:-)

Make no sense? not possible/to hard due to dependencies ?
Should (if time and my *knowledge* allow) have a try at this ? Or lost 
of time ?


Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] scope of variable reduction, cppcheck-error free build and new bugs

[Pierre-André Jacquod]

Hello,
since I had free time, I have taken over to eliminate the "scope 
reduction" warning from cppcheck in order to reduce the noise by checks.


This has been done almost successfully, about 10 such warnings are still 
available due to #ifdefn or macros. This also allowed me to reduce other 
warnings (like hiding of var) and to find some errors introduced by 
recent changes.


Every change has been checked and done "manually", finding also some 
false positives (and one false negative). I have tested several clean 
build with different options, discovering so some too hard scope 
reduction (some #ifdefn masking some if statement). But I guess there 
are - sadly - some configurations where I did not notice that I broke 
something. (Murphy's Law lurks somewhere near us). So my apologies in 
advance.


I will push it during the week-end, once I am finished with rebasing and 
after a last clean build.


If some build option is broken, just revert the concerned commit: they 
are on purpose small and isolated. The log indicates the top directory 
and when possible the file where (the) change(s) has been done.


Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] dmake/win95: deprecated directory ?

[Pierre-André Jacquod]

hello,
I found a directory that seems to be deprecated since win95 is not 
supported anymore.
There is another directory: dmake/winnt which seems to be more or less 
the clone of dmake/win95.


Since I am not able to compile under windows, -hence not able to check 
what I would break -  I mention it here, if someone wants to clean this 
directory and its dependencies... or move them to dmake/winnt if still 
needed.


regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][patch] memset used on struc with std::vector / Windows code

[Pierre-André Jacquod]

Hello,


That should happen in a DdeInstData ctor instead.


I intended to do something easier:
struct DdeInstData
{
short x;

DdeInstData(); // and of course implementing this
}


I've moved it into the ctor now.


Thanks, I was not able to react very quickly, making this during free 
time ... and on Linux. Sorry.


Just for my education [answer is optional]:

The fact to change to class and use boost::noncopyable is an improvement 
not related to this point I guess, since before the copy-ctor and copy 
assignment would have worked with the struct.


Or did I missed something?

Thanks.

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [patch] memset used on struc with std::vector / Windows code

[Pierre-André Jacquod]

hello,
I allow me to send also this patch (I should really find out a Windows 
box in order to compile / test by myself).


In short: since
a39d4eae Remove DECLARE_LIST(DdeConnections,DdeConnection*)

the struct DdeInstData contains a std::vector, but was initialized with 
memset( pData,0,sizeof(DdeInstData) )


So I tried to have a consistent initialization with the new struct layout.

regards
Pierre-André



0007-wrong-initialization-of-DdeInstData-with-memset-desp.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Cppcheck defect when @ is present

[Pierre-André Jacquod]

Hello,


  What's the best thing to do :
- to keep objective C++ parts ?
- to replace objective C++ by plain (with or without boost) C++ ?


for me there are already too many languages and flavour of languages. I 
would stay with  plain C++, not adding objective C++ on top


Just my feelings
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] some cleaning for Windows part - need a review

[Pierre-André Jacquod]

Hello,


I will have a look at your patches on Monday, unless somebody beats me
to it during the weekend.


Thanks,
based on some remarks, here exactly the same patches, but with improved 
commit comments. Will be probably better to integrate these.


Regards
Pierre-André
>From 94bed68189f2298d03972febeb28ebafeadf7d91 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Fri, 9 Sep 2011 21:58:21 +0200
Subject: [PATCH 6/6] [cppchecker] deleted unread var and code in setup_native, vistaspecial.cxx

and simplified coding after that since the logic is not needed
anymore.
---
 .../customactions/shellextensions/vistaspecial.cxx |   60 ++--
 1 files changed, 5 insertions(+), 55 deletions(-)

diff --git a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
index aede073..40ff772 100644
--- a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
+++ b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
@@ -96,7 +96,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 bool bDirectoryRemoved = true;
 
-std::_tstring mystr;
 std::_tstring sPattern = sPath + TEXT("\\") + TEXT("*.*");
 WIN32_FIND_DATA aFindData;
 
@@ -114,9 +113,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 std::_tstring sFileName = aFindData.cFileName;
 
-mystr = "Current short file: " + sFileName;
-// MessageBox(NULL, mystr.c_str(), "Current Content", MB_OK);
-
 if (( strcmp(sFileName.c_str(),sCurrentDir.c_str()) != 0 ) &&
 ( strcmp(sFileName.c_str(),sParentDir.c_str()) != 0 ))
 {
@@ -124,31 +120,11 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 
 if ( aFindData.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY )
 {
-bool fSuccess = RemoveCompleteDirectory(sCompleteFileName);
-if ( fSuccess )
-{
-mystr = "Successfully removed content of dir " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Removed Directory", MB_OK);
-}
-else
-{
-mystr = "An error occurred during removing content of " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Error removing directory", MB_OK);
-}
+RemoveCompleteDirectory(sCompleteFileName);
 }
 else
 {
-bool fSuccess = DeleteFile( sCompleteFileName.c_str() );
-if ( fSuccess )
-{
-mystr = "Successfully removed file " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Removed File", MB_OK);
-}
-else
-{
-mystr = "An error occurred during removal of file " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Error removing file", MB_OK);
-}
+DeleteFile( sCompleteFileName.c_str() );
 }
 }
 
@@ -162,17 +138,9 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 // RemoveDirectory is only successful, if the last handle to the directory is closed
 // -> first removing content -> closing handle -> remove empty directory
 
-bool fRemoveDirSuccess = RemoveDirectory(sPath.c_str());
 
-if ( fRemoveDirSuccess )
-{
-mystr = "Successfully removed dir " + sPath;
-// MessageBox(NULL, mystr.c_str(), "Removed Directory", MB_OK);
-}
-else
+if( !( RemoveDirectory(sPath.c_str()) ) )
 {
-mystr = "An error occurred during removal of empty directory " + sPath;
-// MessageBox(NULL, mystr.c_str(), "Error removing directory", MB_OK);
 bDirectoryRemoved = false;
 }
 }
@@ -189,8 +157,6 @@ extern "C" UINT __stdcall RenamePrgFolder( MSIHANDLE handle )
 std::_tstring sRenameSrc = sOfficeInstallPath + TEXT("program");
 std::_tstring sRenameDst = sOfficeInstallPath + TEXT("program_old");
 
-//MessageBox(NULL, sRenameSrc.c_str(), "INSTALLLOCATION", MB_OK);
-
 bool bSuccess = MoveFile( sRenameSrc.c_str(), sRenameDst.c_str() );
 if ( !bSuccess )
 {
@@ -205,13 +171,6 @@ extern "C" UINT __stdcall RenamePrgFolder( MSIHANDLE handle )
 }
 }
 
-#if 0
-if ( !bSuccess )
-MessageBox(NULL, "Renaming folder failed", "RenamePrgFolder", MB_OK);
-else
-MessageBox(NULL, "Renaming folder successful", "RenamePrgFolder", MB_OK);
-#endif
-
 return ERROR_SUCCESS;
 }
 
@@ -220,25 +179,16 @@ extern "C" UINT __stdcall

Re: [Libreoffice] Bringing some sanity to interline spacing

[Pierre-André Jacquod]

hello



With
http://cgit.freedesktop.org/libreoffice/core/commit/?id=052f181dad89ad34d90513bc9dcd3e3239727933
the new spacing is used only if SAL_USE_NEW_LINEHEIGHT=1 is set in the
environment, else the old metrics are used.


sorry, I am unable to find out the commit and the link point to nothing 
for me. Is the ID the right one?



Which indicates even more that we can't switch just like that to the new
metrics.
Just a remark: the fact of keeping the old / odd behaviour as default is 
a risk that the new one get lost, since few will change to adapt / 
correct to this one. (forgetting it...) Would it not be better to 
activate the new state per default - maybe with a warning / delay ? So 
where needed the code can use the old way, but the new one will be the 
default, and then all people will take much more easily care of.


But I am not the wiser in the game, just here for fun.
Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] some cleaning for Windows part - need a review

[Pierre-André Jacquod]

hello,
liking systematic work, I was cleaning the unreadVariable warning from 
cppchecker.:-) This also let improve my programming knowledge and style...


Here a bunch of changes that touch only Win product,... that I am unable 
to test, having only unix.


Neverless, I did it would it be to reduce the warning noise (also some 
real coding error are popping out sometimes...) Could someone at least 
import and compile it with a Windows box?


By the way, just a question: from which version is Windows supported? 
some function names and comment let think me that some part could be 
deprecated ? (see example below)


Thanks and regards
Pierre-André

static BOOL MoveFileEx9x( LPCSTR lpExistingFileNameA, LPCSTR 
lpNewFileNameA, DWORD dwFlags )

{
BOOLfSuccess = FALSE;   // assume failure

// Windows 9x has a special mechanism to move files after reboot
>From 54384140202fb9446b735d6bd5a08b351dc1a2b7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Fri, 9 Sep 2011 21:58:21 +0200
Subject: [PATCH 6/6] [cppchecker] unreadVar warning - deleted unread variable

and simplified coding after that since the logic is not needed
anymore.
---
 .../customactions/shellextensions/vistaspecial.cxx |   60 ++--
 1 files changed, 5 insertions(+), 55 deletions(-)

diff --git a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
index aede073..40ff772 100644
--- a/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
+++ b/setup_native/source/win32/customactions/shellextensions/vistaspecial.cxx
@@ -96,7 +96,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 bool bDirectoryRemoved = true;
 
-std::_tstring mystr;
 std::_tstring sPattern = sPath + TEXT("\\") + TEXT("*.*");
 WIN32_FIND_DATA aFindData;
 
@@ -114,9 +113,6 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 {
 std::_tstring sFileName = aFindData.cFileName;
 
-mystr = "Current short file: " + sFileName;
-// MessageBox(NULL, mystr.c_str(), "Current Content", MB_OK);
-
 if (( strcmp(sFileName.c_str(),sCurrentDir.c_str()) != 0 ) &&
 ( strcmp(sFileName.c_str(),sParentDir.c_str()) != 0 ))
 {
@@ -124,31 +120,11 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 
 if ( aFindData.dwFileAttributes == FILE_ATTRIBUTE_DIRECTORY )
 {
-bool fSuccess = RemoveCompleteDirectory(sCompleteFileName);
-if ( fSuccess )
-{
-mystr = "Successfully removed content of dir " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Removed Directory", MB_OK);
-}
-else
-{
-mystr = "An error occurred during removing content of " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Error removing directory", MB_OK);
-}
+RemoveCompleteDirectory(sCompleteFileName);
 }
 else
 {
-bool fSuccess = DeleteFile( sCompleteFileName.c_str() );
-if ( fSuccess )
-{
-mystr = "Successfully removed file " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Removed File", MB_OK);
-}
-else
-{
-mystr = "An error occurred during removal of file " + sCompleteFileName;
-// MessageBox(NULL, mystr.c_str(), "Error removing file", MB_OK);
-}
+DeleteFile( sCompleteFileName.c_str() );
 }
 }
 
@@ -162,17 +138,9 @@ static BOOL RemoveCompleteDirectory( std::_tstring sPath )
 // RemoveDirectory is only successful, if the last handle to the directory is closed
 // -> first removing content -> closing handle -> remove empty directory
 
-bool fRemoveDirSuccess = RemoveDirectory(sPath.c_str());
 
-if ( fRemoveDirSuccess )
-{
-mystr = "Successfully removed dir " + sPath;
-// MessageBox(NULL, mystr.c_str(), "Removed Directory", MB_OK);
-}
-else
+if( !( RemoveDirectory(sPath.c_str()) ) )
 {
-mystr = "An error occurred during removal of empty directory " + sPath;
-// MessageBox(NULL, mystr.c_str(), "Error removing directory", MB_OK);
 bDirectoryRemoved = false;
 }
 }
@@ -189,8 +157,6 @@ extern "C" UINT __stdcall RenamePrgFolder( MSIHANDLE handle )
 std::_tstring sRenameSrc = sOfficeInstallPath + TEXT("program");
 std::_tstring sRenameDst = sOfficeInstallPath + TEXT(

[Libreoffice] how to handle this bug (if this is one?)

[Pierre-André Jacquod]

hello,
in vcl/win/source/gdi/winlayout.cxx, around line 695 there is:

 long SimpleWinLayout::FillDXArray( long* pDXArray ) const
 {
+if( !mnWidth )
+{
+long mnWidth = mnBaseAdv;
+for( int i = 0; i < mnGlyphCount; ++i )
+mnWidth += mpGlyphAdvances[ i ];
+}

+if( pDXArray != NULL )
 {
+for( int i = 0; i < mnCharCount; ++i )
+ pDXArray[ i ] = mpCharWidths[ i ];
 }

+return mnWidth;
 }

the statement within th IF does not make any sense for my poor 
understanding. As I read the code, the first IF could also be totally 
removed, since as soon as exiting the first IF, all value are lost.


It seems to me that this is more or less what happened with the early 
code before the change of commit 2f382d6c2579a2 in 2003. But I do not 
sucess to match both logic.

Has someone more / better hints?
Thanks
Pierre-André

long SimpleWinLayout::FillDXArray( long* pDXArray ) const
 {
-if( mnWidth && !pDXArray )
-return mnWidth;
-
-long nWidth = 0;

-for( int i = 0; i < mnGlyphCount; ++i )
 {
-int j = !mpChars2Glyphs ? i : mpChars2Glyphs[i];
-nWidth += mpGlyphAdvances[j];
-if( pDXArray )
-pDXArray[i] = nWidth;
 }

-return nWidth;
 }

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

[Libreoffice] code simplification: please logic review, to be sure

[Pierre-André Jacquod]

Hello,
I am trying to wipe some unneeded calls and I see the following:

while(  )
{
-
SwFrm* pFrm;
if( 0 != ( pONd = aIdx.GetNode().GetOLENode() ) &&
aName.Equals( pONd->GetChartTblName() ) &&
0 != ( pFrm = pONd->getLayoutFrm( rVSh.GetLayout() ) ) )
{
}
...
}

knowing that pFrm is never used execpt in the comparision, I wanted to 
simplify to :

   0 != ( pONd->getLayoutFrm( rVSh.GetLayout() )
since the return value of the operator= should be the same as the right 
operand.


But this basically, this just ensure that the return value is not NULL 
(comparing the pointer SwFrm* with 0 )


So I though the final version to be:
if( 0 != ( pONd = aIdx.GetNode().GetOLENode() ) &&
aName.Equals( pONd->GetChartTblName() ) &&
pONd->getLayoutFrm( rVSh.GetLayout() )
{
}

Did I missed something with my logic ?

The code is from line 145 of sw/source/core/doc/docchart.cxx

Thanks a lot for your feed-back

best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [patch] unused variable in Windows build

[Pierre-André Jacquod]

Hello,
a small patch to suppress an unused variable (within a WNT define) 
according cppchecker


Since I can not build on Windows, if someone could review / compile it 
for me before pushing ?


Thanks and regards

Pierre-André


0001-unused-variable-in-Windows-build.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...

[Pierre-André Jacquod]

Hi,


* announcing binfilter as deprecated in 3.4
+ want to warn people in plenty of time
+ officially deprecate it, we drop save support in 3.4


The code cleaning is not yet finished, I still have commits (and done 
commits) that missed the 3.4 freeze (argh, missing free time) and some 
that needs to be done.


>> + be warned - it will die in a new major release soon.

Will be this 3.5 ? Or do you want to wait for the next version? If post 
3.5, then I will continue the cleaning. If no, I may change my work and 
try to perform cleaning (ergh, deletion) as proposed here below.



And also make sure when you remove it completely: Don't remove the
filter-detection part of it. I.e. when a user then opens a
binfilter-covered format, don't present the user with the file-format
selection box, but use a "sorry, support for this format was removed -
open it in 3.4" or similar dialog.



Regards
Pierre-André

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

Re: [Libreoffice] release plan : inconsistency between 3.3.3 and 3.4

[Pierre-André Jacquod]

Hello,
jumping late into the subject, but

On 04/11/2011 12:25 PM, Michael Meeks wrote:

The plan is (of course), to keep releasing 3.3.x releases as long as
people are interested in creating them I suppose[1] - we should come up


May I disagree ?? This is not a very predictable use for all involved: 
users, distros, etc... When to jump to next version? What happens for 
bug discovered in distros ?


Especially if we have 3-4 X.Y release a year


IMHO it is good to have a stable release of 3.3 after releasing 3.4 -

Here I fully agree,

Could it be not possible to have some rules, like the release of version 
X.Y.0 means end of support for X.(Y-2) version. En in case of X.0.0 
version, only the latest (X-1).Y.Z version is supported ?


and that in what-ever X.Y.Z and X.(Y-1).W, only the latest Z and W are 
supported? But this would implies to have at least within the X.Y path 
an update mechanism, especially for Windows.


But this could lead to problems, since distro's have a more slowly pace 
of release.


So what about picking long term support, e.g. 3.5 is long term support, 
means 2 years, what ever happens for the number of releases ?


This kind of scheme would limited (and clarify) the number of release 
that are / could be cared of. (again, usefull with several X.Y a year) 
So if you get a bug report, you know against which release you have to 
test / it will be tested.


Just thinking loud... other wants to do it also? :-)

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Calc's status bar is blank

[Pierre-André Jacquod]

Hello,
I have the same on master.
calc -> ca6285bd996927f797
libs-gui -> e29b73f64c3d5d4cf42
as header.

This is previous libreoffice-3-4 branch, so breakage comes from master.

Actually, I did not notice this before you wrote. But I had build from 
master 1-2 days before the above mentioned commits. (since usually doing 
this during the night), and the whole Calc was havoc on master: all 
icons at the top (short-cuts for function) were away. Being not sure if 
this was a build or a code problem I did a

/.g pull -r and have
make clean && make && make dev-install.

Icons were back, but I did not notice that the status bar was away 
before you mentioned it. I though the build was again ok. Then I assume 
some commit(s) on master broke this. I have no further clue on this 
topic, but I hope this can help you / someone to see the root cause.


regards
Pierre-André

On 04/02/2011 03:48 AM, Kohei Yoshida wrote:

So, as of today, using the libreoffice-3-4 branch build, Calc's status
bar is totally blank.  I have about a week old master build, and that
build shows status bar correctly.

Does anyone have any clue as to what happened?  Failing that, would
anyone be interested in taking a stab at this?  If no one is willing, I
will have to take a look at this at some point, but I could certain use
some help here...

Writer, Draw, Impress etc. all show their status bars correctly.

Kohei



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

Re: [Libreoffice] -Woverloaded-virtual

[Pierre-André Jacquod]

Hello,

On 03/25/2011 02:13 PM, Lubos Lunak wrote:

On Friday 25 of March 2011, Caolán McNamara wrote:

argh!, I meant to say "then things are *not* too bad", not "*too* bad".
I mean that's far less that I would have feared, quite manageable.


  Ok. In that case, if there are no objections, I'll commit my patches.


just a bet: binfilter was off in your try?

So I have some warning more to handle, once I am finished with cleaning. 
And I am always +1 for all what shows potential problems. Else it bites 
you harder later...


regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,

On 03/25/2011 10:12 PM, Caolán McNamara wrote:

On Fri, 2011-03-25 at 22:09 +0100, Pierre-André Jacquod wrote:

something... Hopefully my tests are good And  make check was
successful,.. at last :- )


in case you're relying on it as some oracle :-)


No, the other way around: I run make check to be sure not to break it, 
as I did once:- )


More seriously: I have my set of files for testing, but will nerveless 
be happy and thankful if other are also sometimes trying to use binfilter.

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

Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,
after working, hibernating, rebasing after changes,... and changing my 
way of doing this, I push again some deletions.


I have done some deletions of functions that are not used any more 
within the binfilter and replaced theyre return value. All the code is 
not yet cleaned.


I have done testing as far as I can, and I did not find out that I broke 
something... Hopefully my tests are good And  make check was 
successful,.. at last :- )


regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] .fodt format broken

[Pierre-André Jacquod]

Hello,
after having made a full compile, I have seen that the support for .fodt 
file format (plain xml) is broken. I tested this file format (created a 
file,...) about one month ago, and all was well, but now you just get a 
general I/O error, by reading or saving it.


I do not know it this is a following of the merge with OpenOffice or of 
the de-java xml (which is good).


Do we want to still surpport this format? if no, then I will remove its 
appreance in load & save


If yes, may someone look at it? I do not know this part, and do not have 
currently the time to investigate. I can try to find which commit broke 
it. but not today:- )


best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] [PUSHED] Translate Comments

[Pierre-André Jacquod]

Hello,
looks good, pushed.
Thanks
Pierre-André

On 03/23/2011 11:19 PM, Rob Snelders wrote:

Hi,

I have translated some comments in the libs-core/connectivity-directory.

I submit this patch under LGPLv3+/MPL-Licence.



___
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

Re: [Libreoffice] [PUSHED] [PATCH] Remove commented out code

[Pierre-André Jacquod]

Hello,
all seems to me OK, then I pushed.
Thanks
regards
Pierre-André

On 03/08/2011 12:19 PM, Bálint Dózsa wrote:
> Hi,
> 
> I have removed some commented out code form// //xmloff/.
> My code is under the LGPLv3+/MPL dual license.
> 
> Regards,
> Balint Dozsa
> 
> 
> 
> ___
> 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

Re: [Libreoffice] [PATCH] [PUSHED] Easy Hacks: Translation of Comments from German to English

[Pierre-André Jacquod]

Hello,
thanks, just changed a typo
best regards
Pierre-André

On 03/06/2011 04:10 PM, Daniel Di Marco wrote:
> Hi,
> 
> I translated some more comments. The patch is attached.
> 
> 
> Cheers,
> Daniel
> 
> 
> 
> ___
> 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

Re: [Libreoffice] Remove "using namespace ::rtl"

[Pierre-André Jacquod]

Hello,

> Finally since I'm not sure for the moment about what must be done on
> "using namespace com::sun::star::uno", I did the work on binfilters.

Thanks
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Remove "using namespace ::rtl"

[Pierre-André Jacquod]

Hello,

> Even if binfilters is going to be "extracted" from LO, doesn't it worth
I am doing, this, leting it be only an "import" filter.

> to purge "using namespace ::rtl" from it (I think about the people
I think that when "cross-module" cleaning is done, this is worth to do
it also within binfilter: to get ride of old style, to be consistent
with the rest. But should not be top 1 priority :- )

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED][PATCH]Cleanup comments

[Pierre-André Jacquod]

Hello,
pushed, thanks,
Maybe not forgetting the [patch] tag in subject will help not to miss
your submission.
best regards


On 02/27/2011 04:51 PM, Arnaud Versini wrote:
> Hi,
> 
> This patch remove some useless comments in msfilter.
> 
> Thanks
> 
> -- 
> Arnaud Versini
> 
> 
> 
> ___
> 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

Re: [Libreoffice] Nonsense comments?

[Pierre-André Jacquod]

On 02/25/2011 09:46 PM, Caolán McNamara wrote:

> po files can have translator-comments in them to help translators
> about ambiguous terms/words, while the .src/.sdf format doesn't though,
translation with gettext would support this with comment using key-words
/ tags. Key words are configurable, maybe a convention has been set with
### as marker...

> right ? I recall a problem with trying to get the Spanish translation of
> an obscure paper size (8.5" x 13" ) set as "Oficio" given that this

with gettext, it would be roughly something like
coding in file.cxx:
/* TRANSLATORS paper size (8.5" x 13" ) */
printf("Long Bond");

with xgettext --add-comments TRANSLATORS
the po-file for this language would then looks (after translation) like

#. paper size (8.5" x 13" )
#src: file.cxx 123
msgid "Long Bond"
msgstr "Oficio"


in crazy idea to go to gettext, when really time available : -)
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Comment-translation of writer/sw/source/ui/config

[Pierre-André Jacquod]

On 02/24/2011 08:33 PM, Kohei Yoshida wrote:
> On Thu, 2011-02-24 at 19:46 +0100, Jonathan Aquilina wrote:

>> Martin i think it would be easier as well as not to end up having ur 
>> email black listed for sending out large amounts of emails, but if its 
>> for a single module i would attach them all in one email.
> 
> For the record this is what git send-email --thread --no-change-reply-to
> does, which the guideline mentions.

yes but it does not recommend to make a commit per file for the same
task within the same directory...

Looking at the patches, there are some with 1 line changed in one file.
In this case, I would recommend to have one commit for translation
within a directory.

If you are programming, you will very often not be able to have one
commit with just one file changed, knowing that a commit should be
"compilable and runnable"...

Martin, you can still locally commit as often as you did. But when you
are finished with your work, you can group together commits where it
makes sense. (in your case, e.g. one commit for translation per
directory, except with extra-big file for example). Just beware, still
holds to the rule 1 commit is compilable

For this you can use git rebase -i. At
http://book.git-scm.com/4_interactive_rebasing.html
you have a good explanation.

At the end, you can then send the git send-mail, with the fewer number
of commits. (I am not sure if this could be achieved on the fly, but I
think this could be risky, a least too risky for me...)

I hope this can help
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] binfilter, filter & co: some questions

[Pierre-André Jacquod]

Hello,
still working on this %&@#filter removing and I am crossing within
binfilter/bf_sc a lot of "if" statement, testing if the current handled
format is StarOffice, Excel95, Execl97 etc...

A lot of theses "if" are typically like:
else if (aFltName.EqualsAscii(pFilterLotus))
{
 DBG_BF_ASSERT(0, "STRIP");
}

binfilter should only contain filter for StarOffice format, isn't it?
All these Excel, HTML and other checks are rest of the time this filter
was the main one and could be also cleaned?

A bit more generally, (for my overall understanding)
what is the goal / mean of the filter repository ? What is the logic
behind the
> filters/filter/source/msfilter (or others)
in comparison to directories (e.g)
> calc/sc/source/filter/
> sw/source/filter/

I spend a bit time before realising that the filters could be there:-)

For a global logic, shouldn't filters belong to the filter repository?
Or is the decision taken to split the filter to each
application/repository (calc, writer,..)

Advantage of being within filter would most probably be an easier way to
deprecate filter and will most probably promote a good separation
between the filter and the application. T

thanks for lightening my mind.
Regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Patch handling guideline

[Pierre-André Jacquod]

Hello,
if you do not mind, I wanted to propose the following points:

patch submission:
creating patches with
>> git format-patch
or
sending them directly with
git send-email

I suggest the following options:
--thread and
--no-chain-reply-to
if there are several patches, which results in:
[PATCH 0/2] Here is what I did...
 > [PATCH 1/2] Clean up and tests
 > [PATCH 2/2] Implementation
(all following mails as reply to the first one)

for applying, I would propose:
git am
which takes over user / date / commit message from the send message.
Should we generally use the
--signoff
option in order to let a trace of who has pushed this?

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,
after quite a long time, I have done a push again concerning this topic.
Sorry, I was very busy at work and had barely the time to go ahead.

Here is the following work in cleaning within binfilter/bf_sw the code
allowing to write in StarWriter format.

Without touching dependencies outside of binfilter/bf_sw (which I want
to avoid currently), I can’t remove more parts.

So I will start on the next StarOffice format.

Best regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,

>   Wonderful :-) do you want help with this ? we could add an easy hack,
> and ask people to contact you, for impress / calc etc.
> 
Thanks for this point. I will think if this is easily feasible. But I am
still myself on the (intensive) learning part, so I currently do not
feel me yet enough confident to describe an easy hack :- )
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,

On 01/24/2011 03:43 PM, Caolán McNamara wrote:
> 
> You also needed to adjust the smoketest "make check" because that has a
> save as staroffice binary file format test in it. I noticed this failed
> this morning and bodged it up to work again.

Oops, sorry, I was not aware of it. Could you just give me a hint where
the code is, so I can have a look?
Thanks
Pierre-André

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

[Libreoffice] Announcement: StarOffice file-format not available any more for saving

[Pierre-André Jacquod]

Hello,
from now I have started to delete within binfilter the code allowing to
*save* using the StarOffice file format. The import (read) is
still possible and will remain. Bye bye saving sdw, sxw 

This will of course not happens in one go...

With this push, I have done the following changes:
* StarWriter does not export anymore
* start of deletion of functions within binfilter/bf_sw, i.e StarWriter
format

For testing:
I have my set of files created with those formats, allowing me to test
the reading functionality while deleting code. But if other wants to
test it to ensure also that nothing has been broken, I would be happy.

In order to allow interested to test easily, I will push my changes to
master at periodic intervals (each 2-3 weeks, I think/hope if free time
allows), grouping them and making a short announce as reply to this mail.

Best regards
Pierre-André

PS: do not forget the --enable-binfilter flag, if you want to check it
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] error compiling in libs-gui/canevas

[Pierre-André Jacquod]

hello,
there is an error compiling canevas:

the reason: in vcl/inc/vcl/sysdata.hxx
there has been a change at line 125:

-void* pRenderFormat;  // render format for drawable
+void* pXRenderFormat;  // render format for drawable

This produce the error (see below) in canevas compilation.
Since I have no idea about this part and do not know why this change has
been made, I do not risk to fix this of my own...   

Could someone who understands better than me this part fix it? or give
me a go to just change in
libs-gui/canvas/source/cairo/cairo_xlib_cairo.cxx (and if needed other
canevas part) the pRenderFormat to pXRenderFormat ... without much
understanding :- )

regards
Pierre-André

Compiling: canvas/source/cairo/cairo_xlib_cairo.cxx
.../libs-gui/canvas/source/cairo/cairo_xlib_cairo.cxx: In constructor
'cairo::X11SysData::X11SysData(const SystemGraphicsData&)':

.../libs-gui/canvas/source/cairo/cairo_xlib_cairo.cxx:79:31: error:
'const struct SystemGraphicsData' has no member named 'pRenderFormat'

.../libs-gui/canvas/source/cairo/cairo_xlib_cairo.cxx: In member
function 'virtual boost::shared_ptr
cairo::X11Surface::createVirtualDevice() const':

/libs-gui/canvas/source/cairo/cairo_xlib_cairo.cxx:266:29: error:
'struct SystemGraphicsData' has no member named 'pRenderFormat'
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] making binfilter aka StarOffice FileFormat read-only

[Pierre-André Jacquod]

Hi,
On 01/14/2011 07:33 PM, Regina Henschel wrote:
> Hi all,
> 
> there is something wrong actually. Removing *Export*-filter is
> reasonable, but now in LibO RC3 I cannot *read* my SO5 files.
> 
> Kind regards
> Regina
Up to now, nothing has been committed. On trunk master, all is OK, I
just tested it.
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] making binfilter aka StarOffice FileFormat read-only

[Pierre-André Jacquod]

Hi Jan / Hi Michael,

some more testing and code reading. Here some answers.
[I was writing this mail while testing, mostly written before Michael's
mail. Hence this will answers both mails. ]

> This is a good point - as you say, I agree we can omit the creation of
> the lock file.  It would be good to double-check how it behaves when you
> have a format where you have one filter for reading, and other one for
> writing ;-)  

The behaviour here is quite straight forward:

   * at opening the import only filter in rw, it set the
lock-file for this file (e.g. a swd file)
   * if changes have been done but not yet saved, the backup file in
"current format" is created as back-up
   * when clicking save, it opens the "save as" pop-up. You have to
choose an EXPORT format. On saving, the lock on the previous (let's say
swd file) is released and a new lock on the new file (let's say odf) is
created. From now one you work with / within the new file/ file format.

> But either way, I don't think that actually creating the
> lock even though the filter is import-only is that serious issue, ie.
> you can remove the locking of the file later, it is not blocking your
> work.
Right, seems fair. But I have detected some write function(s) deep in
binfilter (since linked to sw function code, not the generic
binfilter/sfx2 layer) that are called at *opening* when this is not done
in read-only modus  Then I think this is called to set the lock
file. (not yet followed the whole) This is while I directed me towards
read-only mode.

I guess the process should change and do not set a lock-file if this is
opened read-only OR with a filter without export capability.


>> investigate): with opening in read/write and without EXPORT filter, what
>> happens with the auto-save option, after some changes have been done?
> No idea, without testing myself.  I think we could fallback to
> autosaving in ODF format, if we do not do it yet ;-)
Finally, that's OK. See above. And Michael's mail

>> The filter, despite write is not usable (no export). ...
>> So ideally could it be: not export, READONLY and pop-up ?? :- /
> I'd still prefer not to set the read-only flag if possible, it is a
After playing a bit, I agree, and I think it will be possible to handle
that in a proper way.

Just stupid question: should a warning pop-up really be set ?

Finally, making the binfilter import only (i.e without export / write
functionality) is a shared property of ALL file formats which (would not
have) / have not the EXPORT flag set. Nothing to do with legacy or not...

This is why, if a pop-up is still / really wanted, I think this should
be a generic pop-up like:

if ! FLAG_FILTER_EXPORT
 pop-up: this file format is supported only in read modus. If you modify
the document, you will have to save it using another format, which you
may not be able to open with the program that initially created this file
(text should be improved :-)

I found a place to put such a pop-up (but I think this is quite a dirty
place):
in libs-core/sfx2/source/doc/sfxbasemodel.cxx
within SfxBaseModel::load

 // load document
sal_uInt32 nError = ERRCODE_NONE;
if ( !m_pData->m_pObjectShell->DoLoad(pMedium) )
nError=ERRCODE_IO_GENERAL;
+else
+{
+  if( !( pMedium->GetFilter()->GetFilterFlags()
+ &  SFX_FILTER_EXPORT ) )
+  {
+   // here pop-up: this is import only filer
+   // you won't be able to save it within this format
+  }

just after loading the file, but long before being back at the top
level... horrible.

Have someone a better idea where to put it ?

regards
Pierre-André

ps: since Christmas holidays are behind, I will need more time for each
step... doing it during free time:- ).
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] starmath / cppunit breakage in master

[Pierre-André Jacquod]

Hi,

> Does setting
> #define MDDS_HASH_CONTAINER_STLPORT 1
> before
> #include 
> 
> help?
> 
> I also saw someone having a similar issue in the same exact spot, which
> I haven't been able to reproduce.
Maybe this is related. I had also a problem after having upgraded to mds
0.4.0 with an up to date (25.12.2010) git
At the ende, I managed to compile making a hack to 0.4.0 (very
dirty...). Since this part was outside of my understanding, I am not
able to know if the error was from my side or not...
 and since you were "on holliday" I kept it if someone also run in
trouble.  Below more explanation.

Since then, I did not recompile the whole stuff... take too long by me.:- )
regards

>> I guess this is specific to system-mdds.
> Conceptually there should be no difference whether it's system or
> internal, since mdds is just a collection of header files with no
> libraries to build or link against.  From the looks of the log file, it
> *may* have some issues with gcc 4.5.x's implementation of unordered_map,
> but I'm not sure 100%...

I have tried make clean, make distclean
I have used
./autogen.sh --with-num-cpus=2 --without-junit --disable-kde
--enable-binfilter

compiler:
gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux)

I did not success to compile, until I changed:
libo_dev/solver/330/unxlngi6.pro/inc/mdds/hash_container/map.hpp
simulating having MDDS_HASH_CONTAINER_STLPORT defined:

like this:

#else
// c++0x
#include 
#define _mdds_unordered_map_type ::std::hash_map
//#include 
//#define _mdds_unordered_map_type ::std::unordered_map
#endif

Else, I got error like

Compiling: sc/source/core/tool/scmatrix.cxx
In file included from /usr/include/c++/4.5/bits/stl_algobase.h:63:0,
 from /usr/include/c++/4.5/unordered_map:41,
 from
/home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/hash_container/map.hpp:41,
 from
/home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/mixed_type_matrix_flag_storage.hpp:32,
 from
/home/pjacquod/LibO_dev/libo_dev/solver/330/unxlngi6.pro/inc/mdds/mixed_type_matrix.hpp:34,
 from
/home/pjacquod/LibO_dev/libo_dev/clone/calc/sc/source/core/tool/scmatrix.cxx:45:
/usr/include/c++/4.5/bits/cpp_type_traits.h:78:10: error: redefinition
of 'struct _STL::__true_type'
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] making binfilter aka StarOffice FileFormat read-only

[Pierre-André Jacquod]

Hi,

>> in binfilter as read-only filters (using as filter flag
>> SFX_FILTER_OPENREADONLY defined as 0x0001L) This will make the
>> opening read-only. By this way, this is not possible any more to save

> IIRC the resolution was a bit different ;-)  
you are right:-)

> This way the user will be
> unable to modify the document, unless she uses the 'create copy'
> possibility, right?
Exact, or first SaveAs and choosing another format.

> The proposal was to load it so that it is read/write, but issue a
> warning like "The format of the file you opened is legacy, and [...]
> As... menu (and consequently from Save).

> remove EXPORT from filter/source/config/fragments/filters/StarWriter_5_0.xcu

Tested. It works (almost) fine. And since there is no EXPORT anymore,
the filter is not available in SaveAs, and when clicking Save, you get
the SaveAs pop-up automatically. But I have 2 points:

Thus, there is a major difference: With READONLY, no lock-file is
generated when the file is openend. With filter without the EXPORT, the
lock-file is still generated This comes during the load process,
where the SfxMedium::IsReadOnly() function is called in order to decide
if this lock-file has to be created or not.(Not spotted the exact place yet)

Actually, I think this is not a correct behaviour. If the filter is not
EXPORT; there is no reason to create the lock-file ? or ???
Should I consider changing the code of the loading part, in order to not
create a lock-file if the filter has not EXPORT properties? From file
point of view, this is the same case: you can not save this file "as-is".

Second issue I see: (I just though of it right now, did not yet test /
investigate): with opening in read/write and without EXPORT filter, what
happens with the auto-save option, after some changes have been done?
The filter, despite write is not usable (no export). ...

So ideally could it be: not export, READONLY and pop-up ?? :- /

>> c) it seems there are elements in the sfx2 of binfilter that are still
>> called, generated, but have no impact on the running system.
> 
> Yes - I think Caolan's callcatches might help you here a lot.
Though of it and looked, but actually not in the above case.

> As outlined above, my favorite approach would be to 'disconnect' the
> binfilter from the save functionality first, add the dialog on open, and
dialog pop-up just at the end of loading the document ? will search for
the right place.

> I hope I helped a bit, 
yes thanks
> please ask more if not really :-)
Thanks

regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] making binfilter aka StarOffice FileFormat read-only

[Pierre-André Jacquod]

Hello,
these days, I have tried (and not really with full success) to
understand how binfilter works...

My goal: since it is an old legacy format, make StarOffice formats
read-only, and clean binfilter component of all code used for writing files.

Reason: with read-only, you will still be able to read your old files /
archive, but his will push the users to use a current / supported format
in case of change. So a less heavy software, use of well-maintained (see
minutes of tech steering call ... 2010.12.09)

After some code reading here a resume of my understanding. Thanks for
correcting, asking, challenging me. I hope I did not understand it too
wrongly.

An easy (and clean) possibility would be to change the filters defined
in binfilter as read-only filters (using as filter flag
SFX_FILTER_OPENREADONLY defined as 0x0001L) This will make the
opening read-only. By this way, this is not possible any more to save
using these file formats.
(I have not yet found where this is set, but still searching)

Currently, I have simulated it locally adding in
libs-core/sfx2/source/bastyp/fltfnc.cxx: (almost at the end of the
function SfxFilterContainer::ReadSingleFilter_Impl )

if (nFormatVersion < SOFFICE_FILEFORMAT_60)
{
pFilter->nFormatType = ( nFlags | SFX_FILTER_OPENREADONLY);
}

this is not a nice hack, but it demonstrates me that it works / how it
works.

This shows me:
a) it works. Yesss : -)

b) there are functions defined in libs-core and binfilter (sfx2 of
libs-core and sfx2 in binfilters) that are redundant. e.g
SFX_FILTER_OPENREADONLY (and other constant values) are defined in both
filters/binfilter/inc/bf_sfx2/docfilt.hxx
libs-core/sfx2/inc/sfx2/docfilt.hxx

c) it seems there are elements in the sfx2 of binfilter that are still
called, generated, but have no impact on the running system. For exemple
function SfxFilterContainer::ReadExternalFilters (in
binfilter/bf_sfx2/source/bastyp/sfx2_fltfnc.cxx) is still called,
produced me a lot of debug text, but the above mentionned code inserted
at the same place (as in libs-core but within his function) did not
produced any effect. So this function is still called, but its effects
are not taken into account.

d) So binfilter could be simplified if I take out all wrinting stuff,
and not needed section of code still called...

I noticed the following at SaveAs: all StarOffice format were still
available, but were producing an error at saving, since they are now by
me read-only... I did not find the place, but could someone hint me
where this is? Actually, I think the list of format displayed at Save or
SaveAs should contain only "not read-only" filters, something like this
in pseudo-code:

(if (filter.getFlags() && SFX_FILTER_OPENREADONLY) !=
SFX_FILTER_OPENREADONLY)
{ display this filter in save / saveas dialog}
(note: I also saw a function isReadOnly() or something like this that
could be called on filter objects, returning true / false. Is probably
even better...)

I do not think there are currently READONLY filters, but basically, I
think this is a bug not taking this flag into account. And so in one go
all problem solved in switching the binfilter to READ-ONLY. If someone
could help me for this part...

Finaly, at saving, this work like this:
(valid for StarOffice format... beware, other format, other paths)

SfxObjectShell::PreDoSaveAs_Impl(param) in libs-core
SfxObjectShell::SaveTo_Impl(param) for ExporTo in libs-core
SfxObjectShell::PreDoSaveAs_Impl(param)
SfxObjectShell::SaveTo_Impl(param) 2  in sfx2_objstor.cxx
SfxObjectShell::SaveAsOwnFormat( param) in sfx2_objstor.cxx
SfxObjectShell::SaveAs(param) in sfx2_objstor.cxx
SfxObjectShell::SaveInfoAndConfig_Impl(param2)
BasicManager::Store(param)
BasicManager::Store(param2)
BasicLibInfo::Store(param)
StgWriter::Write (param)
Sw3Writer::WriteStorage()
Sw3IO::SaveAs
Sw3IO::Save
ExportTo is finished and has returned

with the ExportTo function going "magically" to the binfilter module. I
did not understood what I read there, with the uno part...

Until (and with) the function BasicLibInfo::Store(param), this the
common part of binfilter for all modules. Then it splits to writer,
calc,...

At opening with read-write filter, some of these write functions are
called (for the lock file). With a read-only filter, this does not
happens. At opening, there is also the dark magic call (:- (  through
uno to go through the different filters one by one for generating them


So how to go ahead?

Here I am asking you:
- is it OK to go ahead with this idea?
- should I make a feature/StarOffice-read-only branch ?
- could someone (help me) implement the sorting in order to ensure that
read-only filters are not available for Save / Save As?

Of course, if going ahead on this way, I will search the code in order
to find the right place for activating the SFX_FILTER_OPENREADONLY flag
as property for the filter, not using this hackhopefully

Thanks for your feed-backs
Regards
Pierre-André

[Libreoffice] fighting with debug macros...

[Pierre-André Jacquod]

Hello,

still trying to learn a bit the code. Compiling without DEBUG on gives
some new warnings:- ) This lead me to look at some code construct. Here
is in pseudo-code a typical construct I am crossing:

var y = ;
var x = ;
code
if ( y > MAXVALUE)
{
ASSERT(x, "out of range"); // only use of var x is here
} // there is no else statement
code

Looking at easy hacks, I also saw that ASSERT is deprecated. I have
looked at the OSL macros, but did not found an equivalent of
ASSERT(condition, message) (defined in
filters/binfilter/inc/bf_sw/errhdl.hxx

But further, this is not very useful for the end-user, since LibO is
shipped without debug-level on. (right? )

So I was thinking:
* either a macro exists to do a "hello user, I will crash. Thanks to
send this report", that is added within the if statement.  ??

* or to change the code to something like:
var y = ...;
#if OSL_DEBUG_LEVEL > 0
var x = ...; /* if this is not possible to insert x below, and the
initialization of x does not change any state */
#endif

code
#if OSL_DEBUG_LEVEL > 0
if ( y > MAXVALUE)
{
ASSERT(x, "txt"); // only use of var x is here
} // there is no else statement
#endif
code

to avoid shipping unneeded code to end-user. This will also make code
execution more efficient, avoiding dummy branches.

By the way:
what is the right way to achieve the goal of the easy hack : align
ASSERT (& friends) macro foo ?

include /ure/sal/inc/osl/diagnose.h in file, and use only OSL_Debug
macros loosing all messages? Is it possible to add an additional
OSL_ASSERT(condition, message) macro? Or not wanted?

Thanks for your inputs.
regards

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

Re: [Libreoffice] binfilter and features...

[Pierre-André Jacquod]

Hi,
> There is alright, a phonecon typically once a week or so. maybe we can
> put this topic on the agenda 
would be great

> and you could dial in if its at a suitable time.

doing this during free time, I may really depend if the possibility
arise or not.

But basically, we could think of a kind of general rule according to the
following points:

Do we want to support the file format X ?
if yes
Is the product that produce this file format as default / main / native
file format out of support ?
if yes
Is this product out of support since more than X (3??) years?
if yes
==> LibO supports this file format as read only. In case of changes, the
user has to choose another file format, supported for writing.

Note: for me, for an average user, having to install a plug-in is not an
option. At least as I see even in my west-european neighborhood, despite
well educated (university-level!) people, but not computer freaks, using
it as a mere tools. I always wonder as people are using computer in a
way much more nearer of using hammers than cars

Of course, if the product is still on support, this is another story,
since there other criteria should determine if this is read or read-write.
But this kind of rule could help to shrink down in a regular manner the
LibO code, having a basis for suppressing some part of the code.

I proposed 3 years, this in average, this is the renewal time for PC's.
Actually, for basic users, this is somewhat longer (about 5 years), but
as you have seen (or not) for docx-format, after 3 years of the
introduction of the new format, people not able to read the new format
are really in trouble.

This also "helps" or forces the end-user to migrate to the new format /
up to date format, without loosing access to its archive. This is a good
help for LibO, I think, avoiding having X former file-format existing
around.

Other views, ideas?
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH 01/16] warning variable unused fix in binfilter bf_sw attr

[Pierre-André Jacquod]

Hello again,
can't figure where the first patch is, currently only 2 -> 16 are on the
list. Here again the first one. But if this is as last time, tomorrow
you will have this mail twice..
regards


Hi,
here some patches to suppress warnings within binfilter.
I took a - sometimes too - conservative approach for doing this. Hope I
did not harm this module
regards


>From 3c2cd665fe8a344626265f6c8a2a3b195556441d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 10:18:51 +0100
Subject: [PATCH 01/16] warning variable unused fix in binfilter bf_sw attr

---
 binfilter/bf_sw/source/core/attr/sw_format.cxx |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/binfilter/bf_sw/source/core/attr/sw_format.cxx b/binfilter/bf_sw/source/core/attr/sw_format.cxx
index fdc874a..c424aa3 100644
--- a/binfilter/bf_sw/source/core/attr/sw_format.cxx
+++ b/binfilter/bf_sw/source/core/attr/sw_format.cxx
@@ -213,7 +213,6 @@ namespace binfilter {
 /*N*/ void SwFmt::CopyAttrs( const SwFmt& rFmt, BOOL bReplace )
 /*N*/ {
 /*N*/ 	// kopiere nur das Attribut-Delta Array
-/*N*/ 	register SwCharFmt* pDropCharFmt = 0;
 /*N*/ 
 /*N*/ 	if ( IsInCache() )
 /*N*/ 	{
-- 
1.7.1

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

[Libreoffice] [PATCH 16/16] removing code due to endless loop

[Pierre-André Jacquod]

regards
>From 6551d69a5fbc85f3af92cada84bf543a083d4453 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 22:05:10 +0100
Subject: [PATCH 16/16] removing code due to endless loop

these part of code have been removed. The While(true) loop
means either that the if statement is never taken, or that
the program hangs there. The second case is not safe, the first
case means that this code is not needed.
---
 binfilter/bf_sw/source/core/txtnode/sw_thints.cxx |   23 -
 1 files changed, 0 insertions(+), 23 deletions(-)

diff --git a/binfilter/bf_sw/source/core/txtnode/sw_thints.cxx b/binfilter/bf_sw/source/core/txtnode/sw_thints.cxx
index 06b91e2..1ad 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_thints.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_thints.cxx
@@ -923,16 +923,6 @@ using namespace ::com::sun::star::i18n;
 /*N*/
 /*N*/ 	if( pNd == this )
 /*N*/ 	{
-/*?*/ 		if( aThisSet.Count() )
-/*?*/ 		{
-/*?*/ 			SfxItemIter aIter( aThisSet );
-/*?*/ 			const SfxPoolItem* pItem = aIter.GetCurItem();
-/*?*/ 			while( TRUE )
-/*?*/ 			{
-DBG_BF_ASSERT(0, "STRIP"); //STRIP001 /*?*/ if( lcl_IsNewAttrInSet( *pSwpHints, *pItem, GetTxt().Len() ) )
-/*?*/ 			}
-/*?*/ 		}
-/*N*/
 /*N*/ 	}
 /*N*/ 	else
 /*N*/ 	{
@@ -947,19 +937,6 @@ using namespace ::com::sun::star::i18n;
 /*N*/ 		{
 /*?*/ 			DBG_BF_ASSERT(0, "STRIP"); //STRIP001 SfxItemIter aIter( aThisSet );
 /*N*/ 		}
-/*N*/
-/*N*/ 		if( aNdSet.Count() )
-/*N*/ 		{
-/*?*/ 			SfxItemIter aIter( aNdSet );
-/*?*/ 			const SfxPoolItem* pItem = aIter.GetCurItem();
-/*?*/ 			while( TRUE )
-/*?*/ 			{
-DBG_BF_ASSERT(0, "STRIP"); //STRIP001 /*?*/ if( lcl_IsNewAttrInSet( *pNd->pSwpHints, *pItem, pNd->GetTxt().Len() ) )
-/*?*/ 			}
-/*?*/
-/*?*/ 			SwFmtChg aTmp1( pNd->GetFmtColl() );
-/*?*/ 			pNd->SwModify::Modify( &aTmp1, &aTmp1 );
-/*N*/ 		}
 /*N*/ 	}
 /*N*/
 /*N*/ 	if( pNd->pSwpHints->CanBeDeleted() )
-- 
1.7.1

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

[Libreoffice] [PATCH 15/16] fix warning unused var in binfilter - bf_sw unocore

[Pierre-André Jacquod]

regards
>From 151194c8a68754f9521bd485a9124f6e08f36239 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 21:58:35 +0100
Subject: [PATCH 15/16] fix warning unused var in binfilter - bf_sw unocore

trying to stay on the safe side, means not always removing the function
call that initialized the parameter. So if this function call changed the
parameter, no issue.
---
 .../bf_sw/source/core/unocore/sw_unocrsrhelper.cxx |2 --
 binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx |3 ---
 .../bf_sw/source/core/unocore/sw_unoframe.cxx  |6 ++
 binfilter/bf_sw/source/core/unocore/sw_unoftn.cxx  |1 -
 binfilter/bf_sw/source/core/unocore/sw_unoidx.cxx  |7 +++
 binfilter/bf_sw/source/core/unocore/sw_unoobj.cxx  |2 +-
 binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx |1 -
 .../bf_sw/source/core/unocore/sw_unoparagraph.cxx  |4 ++--
 binfilter/bf_sw/source/core/unocore/sw_unoport.cxx |2 +-
 .../bf_sw/source/core/unocore/sw_unoportenum.cxx   |5 ++---
 binfilter/bf_sw/source/core/unocore/sw_unosect.cxx |3 ---
 binfilter/bf_sw/source/core/unocore/sw_unosett.cxx |4 +---
 .../bf_sw/source/core/unocore/sw_unostyle.cxx  |   10 --
 binfilter/bf_sw/source/core/unocore/sw_unotbl.cxx  |   11 ---
 14 files changed, 20 insertions(+), 41 deletions(-)

diff --git a/binfilter/bf_sw/source/core/unocore/sw_unocrsrhelper.cxx b/binfilter/bf_sw/source/core/unocore/sw_unocrsrhelper.cxx
index 2f431f2..2969570 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unocrsrhelper.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unocrsrhelper.cxx
@@ -295,7 +295,6 @@ sal_Bool getCrsrPropertyValue(const SfxItemPropertyMap* pMap
 {
 const SwTableNode* pTblNode = pSttNode->FindTableNode();
 SwFrmFmt* pTableFmt = (SwFrmFmt*)pTblNode->GetTable().GetFrmFmt();
-SwTable& rTable = ((SwTableNode*)pSttNode)->GetTable();
 if(FN_UNO_TEXT_TABLE == pMap->nWID)
 {
 Reference< XTextTable >  xTable = SwXTextTables::GetObject(*pTableFmt);
@@ -402,7 +401,6 @@ sal_Bool getCrsrPropertyValue(const SfxItemPropertyMap* pMap
 nPaMEnd = nTmp;
 }
 Sequence< ::rtl::OUString> aCharStyles;
-USHORT nCharStylesFound = 0;
 SwpHints* pHints = pTxtNode->GetpSwpHints();
 for(USHORT nAttr = 0; nAttr < pHints->GetStartCount(); nAttr++ )
 {
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx b/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
index 37cb25e..48fcfa9 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
@@ -1541,7 +1541,6 @@ void SwXGroupShape::add( const Reference< XShape >& xShape ) throw (RuntimeExcep
 SwFrmFmt* pFmt = GetFrmFmt();
 if(pSvxShape && pFmt)
 {
-sal_Bool bOk = FALSE;
 Reference xShapes;
 if( xShapeAgg.is() )
 {
@@ -1594,7 +1593,6 @@ void SwXGroupShape::add( const Reference< XShape >& xShape ) throw (RuntimeExcep
 void SwXGroupShape::remove( const Reference< XShape >& xShape ) throw (RuntimeException)
 {
 SolarMutexGuard aGuard;
-sal_Bool bOk = FALSE;
 Reference xShapes;
 if( xShapeAgg.is() )
 {
@@ -1610,7 +1608,6 @@ void SwXGroupShape::remove( const Reference< XShape >& xShape ) throw (RuntimeEx
 sal_Int32 SwXGroupShape::getCount(void) throw( uno::RuntimeException )
 {
 SolarMutexGuard aGuard;
-sal_Int32 nRet = 0;
 Reference xAcc;
 if( xShapeAgg.is() )
 {
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unoframe.cxx b/binfilter/bf_sw/source/core/unocore/sw_unoframe.cxx
index 4d1fdbb..b8f2fc8 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unoframe.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unoframe.cxx
@@ -1570,7 +1570,7 @@ void SwXFrame::setPropertyToDefault( const OUString& rPropertyName )
 SwFrmFmt* pFmt = GetFrmFmt();
 if(pFmt)
 {
-const SwAttrSet& rFmtSet = pFmt->GetAttrSet();
+pFmt->GetAttrSet();
 const SfxItemPropertyMap* pCur = SfxItemPropertyMap::GetByName(_pMap, rPropertyName);
 if (!pCur)
 throw UnknownPropertyException(OUString ( RTL_CONSTASCII_USTRINGPARAM ( "Unknown property: " ) ) + rPropertyName, static_cast < cppu::OWeakObject * > ( this ) );
@@ -1910,7 +1910,6 @@ void SwXFrame::attachToRange(const uno::Reference< XTextRange > & xTextRange)
 SvInPlaceObjectRef xIPObj;
 if( (*pCLSID) >>= aCLSID )
 {
-sal_Bool bInternal = sal_True;
 if( !aClassName.MakeId( aCLSID ) )
 {
 IllegalArgumentException aExcept;
@@ -2192,7 +2191,7 @@ uno::Reference< XTextCursor >  SwXTextFrame::createTextCursor(void) throw( Runti
 
 SwXTextCursor* pXCrsr = new

[Libreoffice] [PATCH 14/16] fix warning unused param in binfilter bf_sw txtnode

[Pierre-André Jacquod]

regards
>From 1a50712d282fd282ab53deb2fd7fb2e5acfa3807 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 21:23:38 +0100
Subject: [PATCH 14/16] fix warning unused param in binfilter bf_sw txtnode

---
 binfilter/bf_sw/source/core/txtnode/sw_atrfld.cxx  |4 ++--
 .../bf_sw/source/core/txtnode/sw_atrflyin.cxx  |4 ++--
 binfilter/bf_sw/source/core/txtnode/sw_atrftn.cxx  |4 ++--
 binfilter/bf_sw/source/core/txtnode/sw_atrref.cxx  |4 ++--
 binfilter/bf_sw/source/core/txtnode/sw_fmtatr2.cxx |3 ++-
 .../bf_sw/source/core/txtnode/sw_fntcache.cxx  |4 ++--
 binfilter/bf_sw/source/core/txtnode/sw_fntcap.cxx  |2 +-
 7 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/binfilter/bf_sw/source/core/txtnode/sw_atrfld.cxx b/binfilter/bf_sw/source/core/txtnode/sw_atrfld.cxx
index e0f6696..ac6a86b 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_atrfld.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_atrfld.cxx
@@ -115,9 +115,9 @@ namespace binfilter {
 /*N*/ 	}
 /*N*/ }
 
-int SwFmtFld::operator==( const SfxPoolItem& rAttr ) const
+int SwFmtFld::operator==( const SfxPoolItem& /*rAttr*/ ) const
 {
-DBG_BF_ASSERT(0, "STRIP"); return 0; //STRIP001 	ASSERT( SfxPoolItem::operator==( rAttr ), "keine gleichen Attribute" );
+DBG_BF_ASSERT(0, "STRIP"); return 0;
 }
 
 /*N*/ SfxPoolItem* SwFmtFld::Clone( SfxItemPool* ) const
diff --git a/binfilter/bf_sw/source/core/txtnode/sw_atrflyin.cxx b/binfilter/bf_sw/source/core/txtnode/sw_atrflyin.cxx
index 791a7ed..b93a5f2 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_atrflyin.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_atrflyin.cxx
@@ -54,9 +54,9 @@ namespace binfilter {
 /*N*/ {
 /*N*/ }
 
-int __EXPORT SwFmtFlyCnt::operator==( const SfxPoolItem& rAttr ) const
+int __EXPORT SwFmtFlyCnt::operator==( const SfxPoolItem& /*rAttr*/ ) const
 {
-DBG_BF_ASSERT(0, "STRIP"); return 0; //STRIP001 	ASSERT( SfxPoolItem::operator==( rAttr ), "keine gleichen Attribute" );
+DBG_BF_ASSERT(0, "STRIP"); return 0; 
 }
 
 /*N*/ SfxPoolItem* __EXPORT SwFmtFlyCnt::Clone( SfxItemPool* ) const
diff --git a/binfilter/bf_sw/source/core/txtnode/sw_atrftn.cxx b/binfilter/bf_sw/source/core/txtnode/sw_atrftn.cxx
index 0043556..a5a4dd8 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_atrftn.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_atrftn.cxx
@@ -71,9 +71,9 @@ namespace binfilter {
 /*N*/ }
 
 
-int SwFmtFtn::operator==( const SfxPoolItem& rAttr ) const
+int SwFmtFtn::operator==( const SfxPoolItem& /*rAttr*/ ) const
 {
-{DBG_BF_ASSERT(0, "STRIP");} return 0;//STRIP001 	ASSERT( SfxPoolItem::operator==( rAttr ), "keine gleichen Attribute" );
+{DBG_BF_ASSERT(0, "STRIP");} return 0;
 }
 
 
diff --git a/binfilter/bf_sw/source/core/txtnode/sw_atrref.cxx b/binfilter/bf_sw/source/core/txtnode/sw_atrref.cxx
index efb6704..fbb2824 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_atrref.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_atrref.cxx
@@ -60,9 +60,9 @@ namespace binfilter {
 /*N*/ {
 /*N*/ }
 
-int SwFmtRefMark::operator==( const SfxPoolItem& rAttr ) const
+int SwFmtRefMark::operator==( const SfxPoolItem& /*rAttr*/ ) const
 {
-{DBG_BF_ASSERT(0, "STRIP");} return 0;//STRIP001 	ASSERT( SfxPoolItem::operator==( rAttr ), "keine gleichen Attribute" );
+{DBG_BF_ASSERT(0, "STRIP");} return 0;
 }
 
 /*N*/ SfxPoolItem* SwFmtRefMark::Clone( SfxItemPool* ) const
diff --git a/binfilter/bf_sw/source/core/txtnode/sw_fmtatr2.cxx b/binfilter/bf_sw/source/core/txtnode/sw_fmtatr2.cxx
index 5f8c188..3ecfea9 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_fmtatr2.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_fmtatr2.cxx
@@ -113,7 +113,8 @@ using namespace ::rtl;
 /*N*/ {
 /*N*/ 	return pTxtAttr ? pTxtAttr->GetInfo( rInfo ) : FALSE;
 /*N*/ }
-/*N*/ bool SwFmtCharFmt::QueryValue( uno::Any& rVal, BYTE nMemberId ) const
+
+/*N*/ bool SwFmtCharFmt::QueryValue( uno::Any& rVal, BYTE /*nMemberId*/ ) const
 /*N*/ {
 /*N*/ 	String sCharFmtName;
 /*N*/ 	if(GetCharFmt())
diff --git a/binfilter/bf_sw/source/core/txtnode/sw_fntcache.cxx b/binfilter/bf_sw/source/core/txtnode/sw_fntcache.cxx
index 6412152..aa008d8 100644
--- a/binfilter/bf_sw/source/core/txtnode/sw_fntcache.cxx
+++ b/binfilter/bf_sw/source/core/txtnode/sw_fntcache.cxx
@@ -236,7 +236,7 @@ extern USHORT UnMapDirection( USHORT nDir, const BOOL bVertFormat );
  *
  */
 
-/*N*/ void SwFntObj::CreateScrFont( const ViewShell *pSh, const OutputDevice& rOut )
+/*N*/ void SwFntObj::CreateScrFont( const ViewShell* /*pSh*/, const OutputDevice& /*rOut*/ )
 /*N*/ {DBG_BF_ASSERT(0, "STRIP"); //STRIP001 
 /*N*/ }
 
@@ -377,7 +377,7 @@ extern USHORT UnMapDirection( USHORT nDir, const BOOL bVertFormat );
  */
 
 
-/*N*/ sal_Bool lcl_IsMonoSpaceFont( const OutputDevice* pOut )
+/*N*/ sal_Bool lcl_IsMonoSpac

[Libreoffice] [PATCH 13/16] fix warning in binfilter bf_sw tox

[Pierre-André Jacquod]

regards
>From 239641e4b675424de81e45cb455e66b8127f9ff3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 21:01:39 +0100
Subject: [PATCH 13/16] fix warning in binfilter bf_sw tox

---
 binfilter/bf_sw/source/core/tox/sw_txmsrt.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/binfilter/bf_sw/source/core/tox/sw_txmsrt.cxx b/binfilter/bf_sw/source/core/tox/sw_txmsrt.cxx
index 660a206..a3e9876 100644
--- a/binfilter/bf_sw/source/core/tox/sw_txmsrt.cxx
+++ b/binfilter/bf_sw/source/core/tox/sw_txmsrt.cxx
@@ -413,7 +413,7 @@ USHORT SwTOXAuthority::GetLevel() const
 /*-- 15.09.99 14:28:08---
 
   ---*/
-void SwTOXAuthority::_GetText( String& rTxt, String& rTxtReading )
+void SwTOXAuthority::_GetText( String& rTxt, String& /*rTxtReading*/ )
 {
 //
 rTxt = m_rField.GetFld()->Expand();
-- 
1.7.1

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

[Libreoffice] [PATCH 12/16] fix warning unused var binfilter bf_sw text

[Pierre-André Jacquod]

regards
>From 22f6a25fcbba5eb41b73436f36a9542b2f898ef4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 20:38:53 +0100
Subject: [PATCH 12/16] fix warning unused var binfilter bf_sw text

---
 binfilter/bf_sw/source/core/text/sw_atrstck.cxx  |5 ++---
 binfilter/bf_sw/source/core/text/sw_frmform.cxx  |6 +-
 binfilter/bf_sw/source/core/text/sw_itrform2.cxx |4 ++--
 binfilter/bf_sw/source/core/text/sw_itrtxt.cxx   |4 
 binfilter/bf_sw/source/core/text/sw_porexp.cxx   |2 +-
 binfilter/bf_sw/source/core/text/sw_porfld.cxx   |5 ++---
 binfilter/bf_sw/source/core/text/sw_porlin.cxx   |6 +++---
 binfilter/bf_sw/source/core/text/sw_porrst.cxx   |6 +++---
 binfilter/bf_sw/source/core/text/sw_portxt.cxx   |2 +-
 binfilter/bf_sw/source/core/text/sw_txtfld.cxx   |2 +-
 binfilter/bf_sw/source/core/text/sw_txtfly.cxx   |2 +-
 binfilter/bf_sw/source/core/text/sw_txtftn.cxx   |   15 +++
 binfilter/bf_sw/source/core/text/sw_txthyph.cxx  |2 +-
 13 files changed, 25 insertions(+), 36 deletions(-)

diff --git a/binfilter/bf_sw/source/core/text/sw_atrstck.cxx b/binfilter/bf_sw/source/core/text/sw_atrstck.cxx
index 91eeaec..4c678ac 100644
--- a/binfilter/bf_sw/source/core/text/sw_atrstck.cxx
+++ b/binfilter/bf_sw/source/core/text/sw_atrstck.cxx
@@ -376,7 +376,7 @@ const BYTE StackPos[ RES_TXTATR_WITHEND_END - RES_CHRATR_BEGIN + 1 ] = {
  *  SwAttrHandler::Push()
  */
 
-/*M*/ sal_Bool SwAttrHandler::Push( const SwTxtAttr& rAttr, const SfxPoolItem& rItem, SwFont& rFnt )
+/*M*/ sal_Bool SwAttrHandler::Push( const SwTxtAttr& rAttr, const SfxPoolItem& rItem, SwFont& /*rFnt*/ )
 /*M*/ {
 /*M*/ ASSERT( rItem.Which() < RES_TXTATR_WITHEND_END ||
 /*M*/ RES_UNKNOWNATR_CONTAINER == rItem.Which() ,
@@ -692,12 +692,11 @@ const BYTE StackPos[ RES_TXTATR_WITHEND_END - RES_CHRATR_BEGIN + 1 ] = {
 /*M*/ break;
 /*M*/ 
 /*M*/ USHORT nRotateStack = StackPos[ RES_CHRATR_ROTATE ];
-/*M*/ const SfxPoolItem* pRotateItem = 0;
 /*M*/ const SwTxtAttr* pRotateAttr = aAttrStack[ nRotateStack ].Top();
 /*M*/ 
 /*M*/ if ( pRotateAttr )
 /*M*/ {
-/*?*/DBG_BF_ASSERT(0, "STRIP"); //STRIP001  pRotateItem = lcl_GetItem( *pRotateAttr, RES_CHRATR_ROTATE );
+/*?*/DBG_BF_ASSERT(0, "STRIP");
 /*M*/ }
 /*M*/ else
 /*M*/ rFnt.SetVertical(
diff --git a/binfilter/bf_sw/source/core/text/sw_frmform.cxx b/binfilter/bf_sw/source/core/text/sw_frmform.cxx
index a373014..afa7067 100644
--- a/binfilter/bf_sw/source/core/text/sw_frmform.cxx
+++ b/binfilter/bf_sw/source/core/text/sw_frmform.cxx
@@ -606,8 +606,6 @@ MSHORT FormatLevel::nLevel = 0;
 /*?*/ 		const SwpHints *pHints = pFoll->GetTxtNode()->GetpSwpHints();
 /*?*/ 		if( pHints )
 /*?*/ 		{
-/*?*/ 			SwFtnBossFrm *pFtnBoss = 0;
-/*?*/ 			SwFtnBossFrm *pEndBoss = 0;
 /*?*/ 			for( MSHORT i = 0; i < pHints->Count(); ++i )
 /*?*/ 			{
 /*?*/ const SwTxtAttr *pHt = (*pHints)[i];
@@ -662,8 +660,6 @@ MSHORT FormatLevel::nLevel = 0;
 /*?*/ 		const SwpHints *pHints = GetTxtNode()->GetpSwpHints();
 /*?*/ 		if( pHints )
 /*?*/ 		{
-/*?*/ 			SwFtnBossFrm *pFtnBoss = 0;
-/*?*/ 			SwFtnBossFrm *pEndBoss = 0;
 /*?*/ 			for( MSHORT i = 0; i < pHints->Count(); ++i )
 /*?*/ 			{
 /*?*/ const SwTxtAttr *pHt = (*pHints)[i];
@@ -991,7 +987,7 @@ MSHORT FormatLevel::nLevel = 0;
 /*N*/ 	{   // Wenn wir Zeilen abgeben, darf kein Join auf den Folows gerufen werden,
 /*N*/ 		// im Gegenteil, es muss ggf. sogar ein Follow erzeugt werden.
 /*N*/ 		// Dies muss auch geschehen, wenn die Textmasse komplett im Master
-/*N*/ 		// bleibt, denn es könnte ja ein harter Zeilenumbruch noch eine weitere
+/*N*/ 		// bleibt, denn es k�nnte ja ein harter Zeilenumbruch noch eine weitere
 /*N*/ 		// Zeile (ohne Textmassse) notwendig machen!
 /*N*/ 		nEnd = rLine.GetEnd();
 /*N*/ 		if( GetFollow() )
diff --git a/binfilter/bf_sw/source/core/text/sw_itrform2.cxx b/binfilter/bf_sw/source/core/text/sw_itrform2.cxx
index 2a974cc..9465c2e 100644
--- a/binfilter/bf_sw/source/core/text/sw_itrform2.cxx
+++ b/binfilter/bf_sw/source/core/text/sw_itrform2.cxx
@@ -1445,7 +1445,7 @@ extern sal_Bool IsUnderlineBreak( const SwLinePortion& rPor, const SwFont& rFnt
 /*M*/ 	xub_StrLen nNewStart = nStart + pCurr->GetLen();
 /*M*/ 
 /*M*/ // adjust text if kana compression is enabled
-/*M*/ const SwScriptInfo& rSI = GetInfo().GetParaPortion()->GetScriptInfo();
+/*M*/ GetInfo().GetParaPortion()->GetScriptInfo();
 /*M*/ 
 /*M*/ if ( GetInfo().CompressLine() )
 /*M*/ {
@@ -1535,7 +1535,7 @@ extern sal_Bool IsUnderlineBreak( const SwLinePortion& rPor, const SwFont& rFnt
 /*N*/ 
 /*N*/ 	// Das Dummyflag besitzen Zeilen, die nur Flyportions enthalten, diese
 /*N*/ 	// sollten kein Register etc. beachten.

[Libreoffice] [PATCH 11/16] fix warning unused var in binfilter bf_sw swg

[Pierre-André Jacquod]

regards
>From c8861cfc5de23428356c1a5cf6aaed6d2a0eced3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 20:13:44 +0100
Subject: [PATCH 11/16] fix warning unused var in binfilter bf_sw swg

---
 binfilter/bf_sw/source/core/swg/sw_rdflds.cxx |2 +-
 binfilter/bf_sw/source/core/swg/sw_rdhnt.cxx  |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/binfilter/bf_sw/source/core/swg/sw_rdflds.cxx b/binfilter/bf_sw/source/core/swg/sw_rdflds.cxx
index 4db68bb..fc13bd3 100644
--- a/binfilter/bf_sw/source/core/swg/sw_rdflds.cxx
+++ b/binfilter/bf_sw/source/core/swg/sw_rdflds.cxx
@@ -541,7 +541,7 @@ static SwField* In_SwDocInfoField( SwSwgReader& rPar, SwDocInfoFieldType* pType,
 return new SwDocInfoField( pType, (USHORT)nType | nSubType );
 }
 
-static SwField* In_SwTemplNameField( SwSwgReader& rPar, SwTemplNameFieldType* pType )
+static SwField* In_SwTemplNameField( SwSwgReader& /*rPar*/, SwTemplNameFieldType* pType )
 {
 return new SwTemplNameField( pType, nNewFldFmt );
 }
diff --git a/binfilter/bf_sw/source/core/swg/sw_rdhnt.cxx b/binfilter/bf_sw/source/core/swg/sw_rdhnt.cxx
index e3650e6..27f4857 100644
--- a/binfilter/bf_sw/source/core/swg/sw_rdhnt.cxx
+++ b/binfilter/bf_sw/source/core/swg/sw_rdhnt.cxx
@@ -340,7 +340,7 @@ static USHORT InSWG_SwNoHyphenHere
 }
 
 static USHORT InSWG_SwSoftHyphen
-( SwSwgReader& rPar, SfxItemSet* pSet, SwTxtNode* pNd, xub_StrLen nBgn, xub_StrLen nEnd )
+( SwSwgReader& /*rPar*/, SfxItemSet* pSet, SwTxtNode* pNd, xub_StrLen nBgn, xub_StrLen /*nEnd*/ )
 {
 if( !pSet )
 pNd->Insert( CHAR_SOFTHYPHEN, SwIndex( pNd, nBgn ));
@@ -348,7 +348,7 @@ static USHORT InSWG_SwSoftHyphen
 }
 
 static USHORT InSWG_SwHardBlank
-( SwSwgReader& rPar, SfxItemSet* pSet, SwTxtNode* pNd, xub_StrLen nBgn, xub_StrLen nEnd )
+( SwSwgReader& /*rPar*/, SfxItemSet* pSet, SwTxtNode* pNd, xub_StrLen nBgn, xub_StrLen /*nEnd*/ )
 {
 if( !pSet )
 pNd->Insert( CHAR_HARDBLANK, SwIndex( pNd, nBgn ));
-- 
1.7.1

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

[Libreoffice] [PATCH 10/16] fix warning unused var in binfilter bf_sw sw3io

[Pierre-André Jacquod]

regards
>From 18b052aa37f4adb95f3250de4967b739bd14be11 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 20:07:52 +0100
Subject: [PATCH 10/16] fix warning unused var in binfilter bf_sw sw3io

---
 binfilter/bf_sw/source/core/sw3io/sw_sw3field.cxx |2 +-
 binfilter/bf_sw/source/core/sw3io/sw_sw3imp.cxx   |3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/binfilter/bf_sw/source/core/sw3io/sw_sw3field.cxx b/binfilter/bf_sw/source/core/sw3io/sw_sw3field.cxx
index e014201..fb043ad 100644
--- a/binfilter/bf_sw/source/core/sw3io/sw_sw3field.cxx
+++ b/binfilter/bf_sw/source/core/sw3io/sw_sw3field.cxx
@@ -2303,7 +2303,7 @@ SwAuthorityFieldType* lcl_sw3io_InAuthorityFieldType( Sw3IoImp& rIo )
 ASSERT( !rIo.IsSw31Export(),
 "Wer will denn da ein Script-Feld exportieren" );
 
-BYTE cFlags = ((SwScriptField*)pFld)->IsCodeURL() ? 0x01 : 0x00;
+((SwScriptField*)pFld)->IsCodeURL() ? 0x01 : 0x00;
 
 String aCode;
 if( ((SwScriptField*)pFld)->IsCodeURL() )
diff --git a/binfilter/bf_sw/source/core/sw3io/sw_sw3imp.cxx b/binfilter/bf_sw/source/core/sw3io/sw_sw3imp.cxx
index 0bed171..d1cb2dc 100644
--- a/binfilter/bf_sw/source/core/sw3io/sw_sw3imp.cxx
+++ b/binfilter/bf_sw/source/core/sw3io/sw_sw3imp.cxx
@@ -424,7 +424,7 @@ public:
 /*N*/ 	{
 /*N*/ 		if( pDoc->GetDrawModel() )
 /*N*/ 		{
-/*N*/ 			SdrPage *pPage = pDoc->GetDrawModel()->GetPage( 0 );
+/*N*/ 			pDoc->GetDrawModel()->GetPage( 0 );
 /*N*/ 			SwHiddenDrawObjList_Impl::const_iterator aIter = pHiddenDrawObjs->begin();
 /*N*/ 			while( aIter != pHiddenDrawObjs->end() )
 /*N*/ 			{
@@ -1747,7 +1747,6 @@ const int RES_POOLCOLL_HTML_DT_40 = 0x3007;
 /*N*/ 		// Autoformate in dieser Liste muessen mit einer
 /*N*/ 		// Extension versehen werden!
 /*N*/ 		sal_uInt16 nFmtId =  0;
-/*N*/ 		const String& rName = rFmt.GetName();
 /*N*/ 		// TODO: unicode: correct?
 /*N*/ 		if( rFmt.IsAuto() ) 		// Autoformat
 /*N*/ 			nFmtId = Count()+1; //++nId;
-- 
1.7.1

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

[Libreoffice] [PATCH 09/16] fix warning unused var in binfilter bf_sw ole

[Pierre-André Jacquod]

regards
>From 5a619e9399713a488eeadc484617e630ed9d06ba Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 20:02:57 +0100
Subject: [PATCH 09/16] fix warning unused var in binfilter bf_sw ole

---
 binfilter/bf_sw/source/core/ole/sw_ndole.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/binfilter/bf_sw/source/core/ole/sw_ndole.cxx b/binfilter/bf_sw/source/core/ole/sw_ndole.cxx
index 111943e..8a1a31b 100644
--- a/binfilter/bf_sw/source/core/ole/sw_ndole.cxx
+++ b/binfilter/bf_sw/source/core/ole/sw_ndole.cxx
@@ -85,7 +85,7 @@ public:
 };
 
 void SwOLELRUCache::Commit() {}
-void SwOLELRUCache::Notify( const ::com::sun::star::uno::Sequence< rtl::OUString >& aPropertyNames ) {}
+void SwOLELRUCache::Notify( const ::com::sun::star::uno::Sequence< rtl::OUString >& /*aPropertyNames*/ ) {}
 
 SwOLELRUCache* SwOLEObj::pOLELRU_Cache = 0;
 
-- 
1.7.1

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

[Libreoffice] [PATCH 08/16] fix warning unused var in binfilter bf_sw layout

[Pierre-André Jacquod]

regards
>From 86062da5291cc62d4f378fb8adb366d696ee11b0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 17:32:49 +0100
Subject: [PATCH 08/16] fix warning unused var in binfilter bf_sw layout

---
 binfilter/bf_sw/source/core/layout/sw_atrfrm.cxx   |   22 ++--
 binfilter/bf_sw/source/core/layout/sw_findfrm.cxx  |2 +-
 binfilter/bf_sw/source/core/layout/sw_flowfrm.cxx  |6 ++--
 binfilter/bf_sw/source/core/layout/sw_fly.cxx  |3 +-
 binfilter/bf_sw/source/core/layout/sw_flycnt.cxx   |8 ++--
 binfilter/bf_sw/source/core/layout/sw_flyincnt.cxx |2 +-
 binfilter/bf_sw/source/core/layout/sw_flylay.cxx   |   36 ++--
 binfilter/bf_sw/source/core/layout/sw_frmtool.cxx  |2 +-
 binfilter/bf_sw/source/core/layout/sw_ftnfrm.cxx   |   10 +++---
 binfilter/bf_sw/source/core/layout/sw_hffrm.cxx|2 +-
 binfilter/bf_sw/source/core/layout/sw_layact.cxx   |6 ++--
 binfilter/bf_sw/source/core/layout/sw_layouter.cxx |2 +-
 binfilter/bf_sw/source/core/layout/sw_pagechg.cxx  |6 ++--
 binfilter/bf_sw/source/core/layout/sw_sectfrm.cxx  |   10 +++---
 binfilter/bf_sw/source/core/layout/sw_ssfrm.cxx|3 +-
 binfilter/bf_sw/source/core/layout/sw_tabfrm.cxx   |4 +-
 binfilter/bf_sw/source/core/layout/sw_trvlfrm.cxx  |2 +-
 binfilter/bf_sw/source/core/layout/sw_wsfrm.cxx|1 -
 18 files changed, 47 insertions(+), 80 deletions(-)

diff --git a/binfilter/bf_sw/source/core/layout/sw_atrfrm.cxx b/binfilter/bf_sw/source/core/layout/sw_atrfrm.cxx
index bd7b593..7f3ff8c 100644
--- a/binfilter/bf_sw/source/core/layout/sw_atrfrm.cxx
+++ b/binfilter/bf_sw/source/core/layout/sw_atrfrm.cxx
@@ -1661,7 +1661,7 @@ int SwFmtURL::operator==( const SfxPoolItem &rAttr ) const
 return bRet;
 }
 
-SfxPoolItem* SwFmtURL::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtURL::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwFmtURL( *this );
 }
@@ -1787,21 +1787,21 @@ bool SwFmtURL::PutValue( const uno::Any& rVal, BYTE nMemberId )
 
 // class SwNoReadOnly
 
-SfxPoolItem* SwFmtEditInReadonly::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtEditInReadonly::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwFmtEditInReadonly( Which(), GetValue() );
 }
 
 // class SwFmtLayoutSplit
 
-SfxPoolItem* SwFmtLayoutSplit::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtLayoutSplit::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwFmtLayoutSplit( GetValue() );
 }
 
 // class SwFmtNoBalancedColumns
 
-SfxPoolItem* SwFmtNoBalancedColumns::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtNoBalancedColumns::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwFmtNoBalancedColumns( GetValue() );
 }
@@ -1938,7 +1938,7 @@ bool SwFmtFtnEndAtTxtEnd::PutValue( const uno::Any& rVal, BYTE nMemberId )
 
 // class SwFmtFtnAtTxtEnd
 
-SfxPoolItem* SwFmtFtnAtTxtEnd::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtFtnAtTxtEnd::Clone( SfxItemPool* /*pPool*/ ) const
 {
 SwFmtFtnAtTxtEnd* pNew = new SwFmtFtnAtTxtEnd;
 *pNew = *this;
@@ -1947,7 +1947,7 @@ SfxPoolItem* SwFmtFtnAtTxtEnd::Clone( SfxItemPool* pPool ) const
 
 // class SwFmtEndAtTxtEnd
 
-SfxPoolItem* SwFmtEndAtTxtEnd::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtEndAtTxtEnd::Clone( SfxItemPool* /*pPool*/ ) const
 {
 SwFmtEndAtTxtEnd* pNew = new SwFmtEndAtTxtEnd;
 *pNew = *this;
@@ -1972,7 +1972,7 @@ SwFmtChain::SwFmtChain( const SwFmtChain &rCpy ) :
 SetNext( rCpy.GetNext() );
 }
 
-SfxPoolItem* SwFmtChain::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtChain::Clone( SfxItemPool* /*pPool*/ ) const
 {
 SwFmtChain *pRet = new SwFmtChain;
 pRet->SetPrev( GetPrev() );
@@ -2044,7 +2044,7 @@ int SwFmtLineNumber::operator==( const SfxPoolItem &rAttr ) const
 bCountLines  == ((SwFmtLineNumber&)rAttr).IsCount();
 }
 
-SfxPoolItem* SwFmtLineNumber::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwFmtLineNumber::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwFmtLineNumber( *this );
 }
@@ -2126,7 +2126,7 @@ int SwTextGridItem::operator==( const SfxPoolItem& rAttr ) const
 aColor == ((SwTextGridItem&)rAttr).GetColor();
 }
 
-SfxPoolItem* SwTextGridItem::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwTextGridItem::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwTextGridItem( *this );
 }
@@ -2286,7 +2286,7 @@ bool SwTextGridItem::PutValue( const ::com::sun::star::uno::Any& rVal,
 
 // class SwHeaderAndFooterEatSpacingItem
 
-SfxPoolItem* SwHeaderAndFooterEatSpacingItem::Clone( SfxItemPool* pPool ) const
+SfxPoolItem* SwHeaderAndFooterEatSpacingItem::Clone( SfxItemPool* /*pPool*/ ) const
 {
 return new SwHeaderAndFooterEatSpacingItem( Which(), GetValue() );
 }
@@ -2372,7 +2372,7 @@ SwRect SwFrmFmt::FindLayoutRect( const sal_Bool bPrtArea, const Point* pPoint,
 if( pFrm && pFrm->GetRegisteredIn() != this )
 {
 // die Section hat ke

[Libreoffice] [PATCH 07/16] fix warning unused var in binfilter bf_sw fields

[Pierre-André Jacquod]

regards
>From 0049d6aa3dd25887c742b51a764776103e67daf8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 15:44:52 +0100
Subject: [PATCH 07/16] fix warning unused var in binfilter bf_sw fields

still only fixes, no optimization has been done. On purpose, avoid
introducing new bugs...
---
 binfilter/bf_sw/source/core/fields/sw_authfld.cxx |2 +-
 binfilter/bf_sw/source/core/fields/sw_dbfld.cxx   |2 +-
 binfilter/bf_sw/source/core/fields/sw_docufld.cxx |4 ++--
 binfilter/bf_sw/source/core/fields/sw_fldbas.cxx  |6 +++---
 binfilter/bf_sw/source/core/fields/sw_usrfld.cxx  |2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/binfilter/bf_sw/source/core/fields/sw_authfld.cxx b/binfilter/bf_sw/source/core/fields/sw_authfld.cxx
index 4a1bf01..289ca69 100644
--- a/binfilter/bf_sw/source/core/fields/sw_authfld.cxx
+++ b/binfilter/bf_sw/source/core/fields/sw_authfld.cxx
@@ -402,7 +402,7 @@ USHORT  SwAuthorityFieldType::GetSequencePos(long nHandle)
 //body the directly available text node will be used
 if(!pTxtNode)
 pTxtNode = &rFldTxtNode;
-ULONG nPos = pTxtNode->GetIndex();
+pTxtNode->GetIndex();
 if( pTxtNode->GetTxt().Len() && pTxtNode->GetFrm() &&
 pTxtNode->GetNodes().IsDocNodes() )
 {
diff --git a/binfilter/bf_sw/source/core/fields/sw_dbfld.cxx b/binfilter/bf_sw/source/core/fields/sw_dbfld.cxx
index 435500c..62950a9 100644
--- a/binfilter/bf_sw/source/core/fields/sw_dbfld.cxx
+++ b/binfilter/bf_sw/source/core/fields/sw_dbfld.cxx
@@ -573,7 +573,7 @@ BOOL SwDBNameInfField::PutValue( const ::com::sun::star::uno::Any& rAny, BYTE nM
 
 /*N*/ SwDBNextSetField::SwDBNextSetField(SwDBNextSetFieldType* pTyp,
 /*N*/    const String& rCond,
-/*N*/    const String& rDummy,
+/*N*/    const String& /*rDummy*/ ,
 /*N*/    const SwDBData& rDBData) :
 /*N*/ 	SwDBNameInfField(pTyp, rDBData), aCond(rCond), bCondValid(TRUE)
 /*N*/ {}
diff --git a/binfilter/bf_sw/source/core/fields/sw_docufld.cxx b/binfilter/bf_sw/source/core/fields/sw_docufld.cxx
index 0318cae..e2f0090 100644
--- a/binfilter/bf_sw/source/core/fields/sw_docufld.cxx
+++ b/binfilter/bf_sw/source/core/fields/sw_docufld.cxx
@@ -1254,7 +1254,7 @@ BOOL SwDocInfoField::PutValue( const uno::Any& rAny, BYTE nMId )
 /*N*/ 
 /*N*/ 	if( TYP_CONDTXTFLD == nSubType )
 /*N*/ 	{
-/*N*/ 		SwNewDBMgr* pMgr = pDoc->GetNewDBMgr();
+/*N*/ 		pDoc->GetNewDBMgr();
 /*N*/ 
 /*N*/ 		bValid = sal_False;
 /*N*/ 		String sTmpName;
@@ -1686,7 +1686,7 @@ BOOL SwPostItField::PutValue( const uno::Any& rAny, BYTE nMId )
 /* ---
 
  ---*/
-/*N*/ String SwExtUserFieldType::Expand(sal_uInt16 nSub, sal_uInt32 nFormat) const
+/*N*/ String SwExtUserFieldType::Expand(sal_uInt16 nSub, sal_uInt32 /*nFormat*/) const
 /*N*/ {
 /*N*/ 	SvxAddressItem aAdr;
 /*N*/ 	String aRet( aEmptyStr );
diff --git a/binfilter/bf_sw/source/core/fields/sw_fldbas.cxx b/binfilter/bf_sw/source/core/fields/sw_fldbas.cxx
index 5bc383c..96fda38 100644
--- a/binfilter/bf_sw/source/core/fields/sw_fldbas.cxx
+++ b/binfilter/bf_sw/source/core/fields/sw_fldbas.cxx
@@ -203,10 +203,10 @@ using namespace ::com::sun::star;
 /*N*/ 	return GetPar2();
 /*N*/ }
 
-void SwField::SetPar1(const String& rStr)
+void SwField::SetPar1(const String& /*rStr*/)
 {}
 
-void SwField::SetPar2(const String& rStr)
+void SwField::SetPar2(const String& /*rStr*/)
  {}
 
 /*N*/ USHORT SwField::GetSubType() const
@@ -215,7 +215,7 @@ void SwField::SetPar2(const String& rStr)
 /*N*/ 	return 0;
 /*N*/ }
 
-void SwField::SetSubType(USHORT nType)
+void SwField::SetSubType(USHORT /*nType*/)
 {
 //  ASSERT(0, "Sorry Not implemented");
 }
diff --git a/binfilter/bf_sw/source/core/fields/sw_usrfld.cxx b/binfilter/bf_sw/source/core/fields/sw_usrfld.cxx
index f7862a8..8198a19 100644
--- a/binfilter/bf_sw/source/core/fields/sw_usrfld.cxx
+++ b/binfilter/bf_sw/source/core/fields/sw_usrfld.cxx
@@ -298,7 +298,7 @@ void SwUserField::SetPar2(const String& rStr)
 /*N*/ 		if( GetDoc()->GetDrawModel() && GetDepends() )
 /*?*/ 		{DBG_BF_ASSERT(0, "STRIP"); }//STRIP001 	((SwDPage*)GetDoc()->GetDrawModel()->GetPage( 0 ))->
 /*N*/
-/*N*/ 		sal_Bool bModified = GetDoc()->IsModified();
+/*N*/ 		GetDoc()->IsModified();
 /*N*/ 		GetDoc()->SetModified();
 /*N*/ 	}
 /*N*/ }
-- 
1.7.1

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

[Libreoffice] [PATCH 06/16] warning fix unused var in binfilter bf_sw draw

[Pierre-André Jacquod]

regards
>From eac219396edebdf58deba912b02edac9a7999554 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 15:30:11 +0100
Subject: [PATCH 06/16] warning fix unused var in binfilter bf_sw draw

---
 binfilter/bf_sw/source/core/draw/sw_dcontact.cxx |   75 +++---
 1 files changed, 9 insertions(+), 66 deletions(-)

diff --git a/binfilter/bf_sw/source/core/draw/sw_dcontact.cxx b/binfilter/bf_sw/source/core/draw/sw_dcontact.cxx
index 67d2f4a..18b3149 100644
--- a/binfilter/bf_sw/source/core/draw/sw_dcontact.cxx
+++ b/binfilter/bf_sw/source/core/draw/sw_dcontact.cxx
@@ -221,7 +221,7 @@ namespace binfilter {
 |*
 |*/
 
-/*N*/ SwFlyDrawContact::SwFlyDrawContact( SwFlyFrmFmt *pToRegisterIn, SdrModel *pMod ) :
+/*N*/ SwFlyDrawContact::SwFlyDrawContact( SwFlyFrmFmt *pToRegisterIn, SdrModel* /*pMod*/ ) :
 /*N*/ 	SwContact( pToRegisterIn )
 /*N*/ {
 /*N*/ 	SetMaster( new SwFlyDrawObj() );
@@ -266,7 +266,7 @@ namespace binfilter {
 |*
 |*/
 
-/*N*/ void SwFlyDrawContact::Modify( SfxPoolItem *pOld, SfxPoolItem *pNew )
+/*N*/ void SwFlyDrawContact::Modify( SfxPoolItem* /*pOld*/, SfxPoolItem* /*pNew*/ )
 /*N*/ {
 /*N*/ }
 
@@ -628,7 +628,7 @@ namespace binfilter {
 |*
 |*/
 
-/*N*/ void SwDrawContact::Modify( SfxPoolItem *pOld, SfxPoolItem *pNew )
+/*N*/ void SwDrawContact::Modify( SfxPoolItem* /*pOld*/, SfxPoolItem* pNew )
 /*N*/ {
 /*N*/ 	//Es kommen immer Sets herein.
 /*N*/ 	//MA 03. Dec. 95: Falsch es kommen nicht immer Sets herein
@@ -984,63 +984,6 @@ void SwDrawContact::ConnectToLayout( const SwFmtAnchor* pAnch )
 }
 }
 break;
-/*
-case FLY_AT_FLY:
-{
-if( pAnch->GetCntntAnchor() ) // LAYER_IMPL
-{
-SwFrm *pAnchor = 0;
-//Erst einmal ueber den Inhalt suchen, weil konstant schnell. Kann
-//Bei verketteten Rahmen aber auch schief gehen, weil dann evtl.
-//niemals ein Frame zu dem Inhalt existiert. Dann muss leider noch
-//die Suche vom StartNode zum FrameFormat sein.
-SwNodeIndex aIdx( pAnch->GetCntntAnchor()->nNode );
-SwCntntNode *pCNd = pFmt->GetDoc()->GetNodes().GoNext( &aIdx );
-if ( pCNd && 0 != (pAnchor = pCNd->GetFrm( 0, 0, FALSE ) ) )
-pAnchor = pAnchor->FindFlyFrm();
-else
-{
-const SwNodeIndex &rIdx = pAnch->GetCntntAnchor()->nNode;
-SwSpzFrmFmts& rFmts = *pFmt->GetDoc()->GetSpzFrmFmts();
-for( USHORT i = 0; i < rFmts.Count(); ++i )
-{
-SwFrmFmt *pFmt = rFmts[i];
-SwFlyFrmFmt* pFlyFmt;
-if( 0 != (pFlyFmt = PTR_CAST( SwFlyFrmFmt, pFmt )) &&
-pFlyFmt->GetCntnt().GetCntntIdx() && //#57390#, Reader
-rIdx == *pFlyFmt->GetCntnt().GetCntntIdx() )
-{
-pAnchor = pFlyFmt->GetFrm( 0, FALSE );
-break;
-}
-}
-}
-if ( pAnchor )	//Kann sein, dass der Anker noch nicht existiert
-{
-pAnchor->FindFlyFrm()->AppendDrawObj( this );
-bSetAnchorPos = false;
-}
-}
-}
-break;
-*/
-/*
-case FLY_IN_CNTNT:
-{
-ClrContourCache( GetMaster() );
-SwCntntNode *pNode = GetFmt()->GetDoc()->
-GetNodes()[pAnch->GetCntntAnchor()->nNode]->GetCntntNode();
-SwCntntFrm *pCntnt = pNode->GetFrm( 0, 0, FALSE );
-if ( pCntnt )
-{
-//Kann sein, dass der Anker noch nicht existiert
-pCntnt->AppendDrawObj( this );
-pCntnt->InvalidatePrt();
-}
-bSetAnchorPos = false;
-}
-break;
-*/
 #ifdef DBG_UTIL
 default:	ASSERT( FALSE, "Unknown Anchor." );
 #endif
@@ -1195,7 +1138,7 @@ const Point SwDrawVirtObj::GetOffset() const
 return maOffset;
 }
 
-void SwDrawVirtObj::operator=( const SdrObject& rObj )
+void SwDrawVirtObj::operator=( const SdrObject& /*rObj*/ )
 {
 DBG_BF_ASSERT(0, "STRIP");//STRIP001 
 }
@@ -1334,7 +1277,7 @@ void SwDrawVirtObj::RecalcBoundRect()
 
 bool SwDrawVirtObj::Paint(ExtOutputDevice& rOut, const SdrPaintInfoRec& rInfoRec) const
 {
-bool bRet;
+bool bRet = FALSE;

[Libreoffice] [PATCH 05/16] warning fix unused var in binfilter bf_sw docnode

[Pierre-André Jacquod]

regards
>From dafaabb2c38990bf4141c6074e15f0ca35d7e160 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 15:19:44 +0100
Subject: [PATCH 05/16] warning fix unused var in binfilter bf_sw docnode

only warning removal, not code optimization, hence some function calls that
may not be needed anymore left behind.
---
 binfilter/bf_sw/source/core/docnode/sw_ndsect.cxx  |5 ++---
 binfilter/bf_sw/source/core/docnode/sw_ndtbl.cxx   |1 -
 binfilter/bf_sw/source/core/docnode/sw_node.cxx|2 +-
 binfilter/bf_sw/source/core/docnode/sw_section.cxx |4 ++--
 .../bf_sw/source/core/docnode/sw_swbaslnk.cxx  |2 +-
 5 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/binfilter/bf_sw/source/core/docnode/sw_ndsect.cxx b/binfilter/bf_sw/source/core/docnode/sw_ndsect.cxx
index 9612c0d..441f3ca 100644
--- a/binfilter/bf_sw/source/core/docnode/sw_ndsect.cxx
+++ b/binfilter/bf_sw/source/core/docnode/sw_ndsect.cxx
@@ -437,7 +437,7 @@ namespace binfilter {
 /*N*/ 	SwSection* pSection = pFmt->GetSection();
 /*N*/ /// OD 04.10.2002 #102894#
 /*N*/ /// remember hidden condition flag of SwSection before changes
-/*N*/ bool bOldCondHidden = pSection->IsCondHidden() ? true : false;
+/*N*/ pSection->IsCondHidden() ? true : false;
 /*N*/
 /*N*/ 	if( *pSection == rSect )
 /*N*/ 	{
@@ -649,7 +649,6 @@ namespace binfilter {
 /*N*/ 		else
 /*?*/ 			new SwTxtNode( aInsPos, (SwTxtFmtColl*)GetDoc()->GetDfltTxtFmtColl() );
 /*N*/ 	}
-/*N*/ 	SwEndNode* pEndNd = new SwEndNode( aInsPos, *pSectNd );
 /*N*/
 /*N*/ 	pSectNd->GetSection() = rSection;
 /*N*/ 	SwSectionFmt* pSectFmt = pSectNd->GetSection().GetFmt();
@@ -778,7 +777,7 @@ namespace binfilter {
 /*N*/ pLast = aIter++;
 /*N*/ 		}
 /*N*/ 	}
-/*N*/ 	SwDoc* pDoc = GetDoc();
+/*N*/ 	GetDoc();
 /*N*/
 /*N*/ 	SwSectionFmt* pFmt = pSection->GetFmt();
 /*N*/ 	if( pFmt )
diff --git a/binfilter/bf_sw/source/core/docnode/sw_ndtbl.cxx b/binfilter/bf_sw/source/core/docnode/sw_ndtbl.cxx
index 62293df..4a0616b 100644
--- a/binfilter/bf_sw/source/core/docnode/sw_ndtbl.cxx
+++ b/binfilter/bf_sw/source/core/docnode/sw_ndtbl.cxx
@@ -227,7 +227,6 @@ static bool lcl_IsItemSet(const SwCntntNode & rNode, USHORT which)
 SwStartNode* pSttNd = new SwStartNode( aEndIdx, ND_STARTNODE,
 SwTableBoxStartNode );
 pSttNd->pStartOfSection = pTblNd;
-SwEndNode* pEndNd = new SwEndNode( aEndIdx, *pSttNd );
 
 pPrvBox = new SwTableBox( pBoxFmt, *pSttNd, pLine );
 
diff --git a/binfilter/bf_sw/source/core/docnode/sw_node.cxx b/binfilter/bf_sw/source/core/docnode/sw_node.cxx
index b25a262..531f27a 100644
--- a/binfilter/bf_sw/source/core/docnode/sw_node.cxx
+++ b/binfilter/bf_sw/source/core/docnode/sw_node.cxx
@@ -1144,7 +1144,7 @@ using namespace ::com::sun::star::i18n;
 // in pIdx kann die 2. Position returnt werden.
 /*N*/ int SwCntntNode::CanJoinPrev( SwNodeIndex* pIdx ) const
 /*N*/ {
-/*N*/ 	const SwNodes& rNds = GetNodes();
+/*N*/ 	GetNodes();
 /*N*/ 	BYTE nNdType = GetNodeType();
 /*N*/ 	SwNodeIndex aIdx( *this, -1 );
 /*N*/
diff --git a/binfilter/bf_sw/source/core/docnode/sw_section.cxx b/binfilter/bf_sw/source/core/docnode/sw_section.cxx
index 30052bf..26b8d11 100644
--- a/binfilter/bf_sw/source/core/docnode/sw_section.cxx
+++ b/binfilter/bf_sw/source/core/docnode/sw_section.cxx
@@ -115,7 +115,7 @@ namespace binfilter {
 /*N*/ 	SwSectionPtr pParentSect = GetParent();
 /*N*/ 	if( pParentSect )
 /*N*/ 	{
-/*N*/ 		bool bPHFlag = pParentSect->IsHiddenFlag();
+/*N*/ 		pParentSect->IsHiddenFlag();
 /*N*/ 		if( pParentSect->IsHiddenFlag() )
 /*?*/ 			SetHidden( TRUE );
 /*N*/
@@ -1132,7 +1132,7 @@ void SwSectionFmt::MakeFrms()
 
 
 
-/*N*/ BOOL SwIntrnlSectRefLink::IsInRange( ULONG nSttNd, ULONG nEndNd, xub_StrLen nStt, xub_StrLen /*nEnd */) const
+/*N*/ BOOL SwIntrnlSectRefLink::IsInRange( ULONG nSttNd, ULONG nEndNd, xub_StrLen /*nStt*/, xub_StrLen /*nEnd */) const
 /*N*/ {
 /*N*/ 	SwStartNode* pSttNd = rSectFmt.GetSectionNode( FALSE );
 /*N*/ 	return pSttNd &&
diff --git a/binfilter/bf_sw/source/core/docnode/sw_swbaslnk.cxx b/binfilter/bf_sw/source/core/docnode/sw_swbaslnk.cxx
index 920f809..75f098d 100644
--- a/binfilter/bf_sw/source/core/docnode/sw_swbaslnk.cxx
+++ b/binfilter/bf_sw/source/core/docnode/sw_swbaslnk.cxx
@@ -368,7 +368,7 @@ namespace binfilter {
 /*?*/ 	0 != (pANd = pDoc->GetNodes()[pAPos->nNode]) &&
 /*?*/ 	0 != (pTblNd = pANd->FindTableNode()) )
 /*?*/ {
-/*?*/ 	BOOL bLastGrf = !pTblNd->GetTable().DecGrfsThatResize();
+/*?*/ 	pTblNd->GetTable().DecGrfsThatResize();
 /*?*/ 	SwHTMLTableLayout *pLayout =
 /*?*/ 		pTblNd->GetTable().GetHTMLTableLayout();
 /*?*/ 	if(	pLayout )
-- 
1.7.1

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

[Libreoffice] [PATCH 04/16] warning fix for unused var in binfilter bf_sw doc

[Pierre-André Jacquod]

regards
>From 76026a3ef610c3b348f2fa514591e452eff3cd8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 14:56:23 +0100
Subject: [PATCH 04/16] warning fix for unused var in binfilter bf_sw doc

This is warning removing, not code optimization => minimum risks have
been taken and some function calls left behind are probably not usefull
anymore. But goal is not to produce new bugs. Once all warnings removed,
if needed we can do code optimization
---
 binfilter/bf_sw/source/core/doc/sw_docbm.cxx|7 ++--
 binfilter/bf_sw/source/core/doc/sw_doccorr.cxx  |8 ++---
 binfilter/bf_sw/source/core/doc/sw_docdesc.cxx  |   19 ---
 binfilter/bf_sw/source/core/doc/sw_docedt.cxx   |   10 +-
 binfilter/bf_sw/source/core/doc/sw_docfld.cxx   |   15 +++--
 binfilter/bf_sw/source/core/doc/sw_docfly.cxx   |   23 +++--
 binfilter/bf_sw/source/core/doc/sw_docfmt.cxx   |   29 +
 binfilter/bf_sw/source/core/doc/sw_docftn.cxx   |   18 +-
 binfilter/bf_sw/source/core/doc/sw_doclay.cxx   |4 +-
 binfilter/bf_sw/source/core/doc/sw_docnum.cxx   |   39 +--
 binfilter/bf_sw/source/core/doc/sw_docredln.cxx |   17 +-
 binfilter/bf_sw/source/core/doc/sw_doctxm.cxx   |4 +--
 binfilter/bf_sw/source/core/doc/sw_tblrwcl.cxx  |2 +-
 13 files changed, 43 insertions(+), 152 deletions(-)

diff --git a/binfilter/bf_sw/source/core/doc/sw_docbm.cxx b/binfilter/bf_sw/source/core/doc/sw_docbm.cxx
index f0ce7bb..fa28dea 100644
--- a/binfilter/bf_sw/source/core/doc/sw_docbm.cxx
+++ b/binfilter/bf_sw/source/core/doc/sw_docbm.cxx
@@ -165,13 +165,13 @@ namespace binfilter {
 /*N*/{
 /*?*/	if( bBkmrk )
 /*?*/	{
-/*?*/		USHORT nCount = pBookmarkTbl->Count();
+/*?*/		pBookmarkTbl->Count();
 /*?*/		USHORT i = 0;
 /*?*/		do {
 /*?*/			if(!(*pBookmarkTbl)[i]->IsBookMark())
-/*?*/nPos++;
+/*?*/++nPos;
 /*?*/
-/*?*/			i++;
+/*?*/			++i;
 /*?*/		}
 /*?*/		while( i < nPos || !(*pBookmarkTbl)[nPos]->IsBookMark() );
 /*?*/	}
@@ -324,7 +324,6 @@ namespace binfilter {
 /*N*/ 	for( nCnt = 0; nCnt < rTbl.Count(); ++nCnt )
 /*N*/ 	{
 /*N*/ 		// liegt auf der Position ??
-/*N*/ 		int eType = BKMK_POS_NONE;
 /*N*/ 		SwRedline* pRedl = rTbl[ nCnt ];
 /*N*/
 /*N*/ 		SwPosition *pRStt = &pRedl->GetBound(TRUE),
diff --git a/binfilter/bf_sw/source/core/doc/sw_doccorr.cxx b/binfilter/bf_sw/source/core/doc/sw_doccorr.cxx
index ff0e123..da64d57 100644
--- a/binfilter/bf_sw/source/core/doc/sw_doccorr.cxx
+++ b/binfilter/bf_sw/source/core/doc/sw_doccorr.cxx
@@ -146,12 +146,11 @@ namespace binfilter {
 /*N*/ 	 const xub_StrLen nOffset,
 /*N*/ 	 BOOL bMoveCrsr )
 /*N*/ {
-/*N*/ 	const SwNode* pOldNode = &rOldNode.GetNode();
+/*N*/ 	&rOldNode.GetNode();
 /*N*/ 	SwPosition aNewPos( rNewPos );
 /*N*/ 
 /*N*/ 	{ // erstmal die Bookmark korrigieren
 /*N*/ 		register SwBookmarks& rBkmks = *pBookmarkTbl;
-/*N*/ 		register SwBookmark* pBkmk;
 /*N*/ 		for( USHORT n = 0; n < rBkmks.Count(); ++n )
 /*N*/ 		{
 /*?*/ 			DBG_BF_ASSERT(0, "STRIP"); //STRIP001 // liegt auf der Position ??
@@ -282,11 +281,10 @@ namespace binfilter {
 /*N*/ 	 const SwPosition& rNewPos,
 /*N*/ 	 BOOL bMoveCrsr )
 /*N*/ {
-/*N*/ 	const ULONG nSttNode = rStartNode.GetIndex();
-/*N*/ 	const ULONG nEndNode = rEndNode.GetIndex();
+/*N*/ 	rStartNode.GetIndex();
+/*N*/ 	rEndNode.GetIndex();
 /*N*/ 	SwPosition aNewPos( rNewPos );
 /*N*/ 
-/*N*/ //	if( !DoesUndo() )
 /*N*/ 		// erstmal die Bookmarks/Redlines korrigieren
 /*N*/ 		_DelBookmarks( rStartNode, rEndNode );
 /*N*/ 
diff --git a/binfilter/bf_sw/source/core/doc/sw_docdesc.cxx b/binfilter/bf_sw/source/core/doc/sw_docdesc.cxx
index 3f2db13..2d509f6 100644
--- a/binfilter/bf_sw/source/core/doc/sw_docdesc.cxx
+++ b/binfilter/bf_sw/source/core/doc/sw_docdesc.cxx
@@ -838,25 +838,6 @@ extern SvPtrarr *pGlobalOLEExcludeList;
 /*N*/
 /*N*/ }
 
-/*
- *	Kleiner Hack;
- *
-const SwPageDesc& SwDoc::GetPageDesc( USHORT i ) const
-{
-if( !i && !aPageDescs.Count() )// noch keiner vorhanden?
-((SwDoc*)this)->InitPageDescs();		//Default PageDescriptor
-return *aPageDescs[i];
-}
-
-SwPageDesc& SwDoc::_GetPageDesc( USHORT i ) const
-{
-if( !i && !aPageDescs.Count() )			// noch keiner vorhanden?
-((SwDoc*)this)->InitPageDescs();		//Default PageDescriptor
-return *aPageDescs[i];
-}
-*/
-
-
 
 /*N*/ IMPL_LINK( SwDoc, DoUpdateModifiedOLE, Timer *, pTimer )
 /*N*/ {
diff --git a/binfilter/bf_sw/source/core/doc/sw_docedt.cxx b/binfilter/bf_sw/source/core/doc/sw_docedt.cxx
index 0a19f58..84de4dc 100644
--- a/binfilter/bf_sw/source/core/doc/sw_docedt.cxx
+++ b/binfilter/bf_sw/source/core/doc/sw_docedt.cxx
@@ -132,11 +132,6 @@ SV_IMPL_PTRARR( SaveBookmarks, SaveBookmark* )
 /*N*/ }
 
 
-
-
-
-// 
-
 /*N*/ _SaveRedlEndPosForRestore::_SaveRedlEndPosForRestore( const SwNodeIndex& rInsIdx )
 /*N*/ 	: pSavArr( 0 ), pSavIdx( 0 )
 /*N*/

[Libreoffice] [PATCH 03/16] fix warning unused var in binfilter bf_sw crsr

[Pierre-André Jacquod]

regards
>From fe0b41fe4378e18478263caf8d09af1f3adafa28 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 11:12:21 +0100
Subject: [PATCH 03/16] fix warning unused var in binfilter bf_sw crsr

this is fixing warning, not optimizing. This means, some functions call
have be left, even if it is possible they are not needed any more
---
 binfilter/bf_sw/source/core/crsr/sw_crsrsh.cxx   |   34 ++---
 binfilter/bf_sw/source/core/crsr/sw_findattr.cxx |   16 ++
 binfilter/bf_sw/source/core/crsr/sw_findcoll.cxx |   17 +++
 binfilter/bf_sw/source/core/crsr/sw_findtxt.cxx  |   23 ---
 binfilter/bf_sw/source/core/crsr/sw_pam.cxx  |   19 +---
 binfilter/bf_sw/source/core/crsr/sw_swcrsr.cxx   |   32 ++--
 binfilter/bf_sw/source/core/crsr/sw_trvlreg.cxx  |   16 +-
 binfilter/bf_sw/source/core/crsr/sw_trvltbl.cxx  |   14 
 binfilter/bf_sw/source/core/crsr/sw_unocrsr.cxx  |   19 +---
 9 files changed, 65 insertions(+), 125 deletions(-)

diff --git a/binfilter/bf_sw/source/core/crsr/sw_crsrsh.cxx b/binfilter/bf_sw/source/core/crsr/sw_crsrsh.cxx
index 17da949..dd19e9b 100644
--- a/binfilter/bf_sw/source/core/crsr/sw_crsrsh.cxx
+++ b/binfilter/bf_sw/source/core/crsr/sw_crsrsh.cxx
@@ -117,11 +117,11 @@ using namespace ::com::sun::star::util;
 
 // gebe den aktuellen zurueck
 
-/*N*/ SwPaM* SwCrsrShell::GetCrsr( bool bMakeTblCrsr ) const
+/*N*/ SwPaM* SwCrsrShell::GetCrsr( bool /*bMakeTblCrsr*/ ) const
 /*N*/ {
 /*N*/ 	if( pTblCrsr )
 /*N*/ 	{
-DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 		if( bMakeTblCrsr && pTblCrsr->IsCrsrMovedUpdt() )
+DBG_BF_ASSERT(0, "STRIP");
 /*N*/ 	}
 /*N*/ 	return pCurCrsr;
 /*N*/ }
@@ -148,19 +148,7 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 		if( bMakeTblCrsr && pTblCrsr->IsC
 
 /*N*/ void SwCrsrShell::EndAction( const BOOL bIdleEnd )
 /*N*/ {
-/*
-//OS: Wird z.B. eine Basic-Action im Hintergrund ausgefuehrt, geht es so nicht
-if( !bHasFocus )
-{
-// hat die Shell nicht den Focus, dann nur das EndAction an
-// die ViewShell weitergeben.
-ViewShell::EndAction( bIdleEnd );
-return;
-}
-*/
-
 /*N*/ 	bool bVis = bSVCrsrVis;
-
 // Idle-Formatierung ?
 /*N*/ 	if( bIdleEnd && Imp()->GetRegion() )
 /*N*/ 	{
@@ -209,7 +197,7 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 		if( bMakeTblCrsr && pTblCrsr->IsC
 /*?*/ 			//der Cursor geupdatet werden; um z.B. den
 /*?*/ 			//TabellenCursor zu erzeugen. Im UpdateCrsr wird
 /*?*/ 			//das jetzt beruecksichtigt!
-DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANGE, bIdleEnd );
+DBG_BF_ASSERT(0, "STRIP");
 /*N*/ 		}
 /*N*/ 		return;
 /*N*/ 	}
@@ -294,7 +282,6 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANG
 /*M*/ 
 /*M*/ 	// erfrage den Count fuer die Start-/End-Actions und ob die Shell
 /*M*/ 	// ueberhaupt den Focus hat
-/*M*/ //	if( ActionPend() /*|| !bHasFocus*/ )
 /*M*/ 	//JP 12.01.98: Bug #46496# - es muss innerhalb einer BasicAction der
 /*M*/ 	//Cursor geupdatet werden; um z.B. den TabellenCursor zu
 /*M*/ 	//erzeugen. Im EndAction wird jetzt das UpdateCrsr gerufen!
@@ -324,8 +311,7 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANG
 /*M*/ 		  pDoc->IsIdxInTbl( pTstCrsr->GetPoint()->nNode ) &&
 /*M*/ 		  ( pTblCrsr ||
 /*M*/ 			pTstCrsr->GetNode( TRUE )->FindStartNode() !=
-/*M*/ 			pTstCrsr->GetNode( FALSE )->FindStartNode() ))
-/*M*/ 		/*|| ( !pTblCrsr && lcl_IsInValueBox( *pTstCrsr, *this ) )*/ )
+/*M*/ 			pTstCrsr->GetNode( FALSE )->FindStartNode() )) )
 /*M*/ 	{DBG_BF_ASSERT(0, "STRIP"); //STRIP001 
 /*M*/ 	}
 /*M*/ 
@@ -557,12 +543,8 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANG
 /*M*/ 		pVisCrsr->Show();   // wieder anzeigen
 /*M*/ }
 
-
-
 // erzeuge eine Kopie vom Cursor und speicher diese im Stack
 
-
-
 /*
  *  Loescht einen Cursor (gesteuert durch bOldCrsr)
  *  - vom Stack oder( bOldCrsr = TRUE )
@@ -572,18 +554,12 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANG
  */
 
 
-
 /*
  * Verbinde zwei Cursor miteinander.
  * Loesche vom Stack den obersten und setzen dessen GetMark im Aktuellen.
  */
 
 
-
-
-
-
-
 /*N*/ void SwCrsrShell::ShowCrsrs( BOOL bCrsrVis )
 /*N*/ {
 /*N*/ 	if( !bHasFocus || bAllProtect || bBasicHideCrsr )
@@ -797,8 +773,6 @@ DBG_BF_ASSERT(0, "STRIP"); //STRIP001  /*?*/ 			UpdateCrsr( SwCrsrShell::CHKRANG
 
 #if defined(DBG_UTIL) || defined(WIN)
 
-
-
 /*N*/ SwCursor* SwCrsrShell::GetSwCrsr( bool bMakeTblCrsr ) const
 /*N*/ {
 /*N*/ 	return (SwCursor*)GetCrsr( bMakeTblCrsr );
diff --git a/binfilter/bf_sw/source/core/crsr/sw_findattr.cxx b/binfilter/bf_sw/source/core/crsr/sw_findattr.cxx
index 03d2972..24d7af4 100644
--- a/binfilter/bf_sw/source/core/crsr/sw_findattr.cxx
+++ b/binfilter/bf_sw/source/core/crsr/sw_

[Libreoffice] [PATCH 02/16] warning fix unused variable in binfilter bf_sw bastyp

[Pierre-André Jacquod]

regards
>From a03ec223cf70c17a1cd6bbf397dc954c8d9d13fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 10:25:53 +0100
Subject: [PATCH 02/16] warning fix unused variable in binfilter bf_sw bastyp

---
 binfilter/bf_sw/source/core/bastyp/sw_calc.cxx|2 +-
 binfilter/bf_sw/source/core/bastyp/sw_swtypes.cxx |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/binfilter/bf_sw/source/core/bastyp/sw_calc.cxx b/binfilter/bf_sw/source/core/bastyp/sw_calc.cxx
index 7cee1dd..76e7026 100644
--- a/binfilter/bf_sw/source/core/bastyp/sw_calc.cxx
+++ b/binfilter/bf_sw/source/core/bastyp/sw_calc.cxx
@@ -454,7 +454,7 @@ static int
 
 
 
-/*N*/ String SwCalc::GetStrResult( double nValue, BOOL bRound )
+/*N*/ String SwCalc::GetStrResult( double nValue, BOOL /*bRound*/ )
 /*N*/ {
 /*N*/ 	if( nValue >= DBL_MAX )
 /*N*/ 		switch( eError )
diff --git a/binfilter/bf_sw/source/core/bastyp/sw_swtypes.cxx b/binfilter/bf_sw/source/core/bastyp/sw_swtypes.cxx
index 198f2a8..60965eb 100644
--- a/binfilter/bf_sw/source/core/bastyp/sw_swtypes.cxx
+++ b/binfilter/bf_sw/source/core/bastyp/sw_swtypes.cxx
@@ -127,9 +127,9 @@ IMPL_FIXEDMEMPOOL_NEWDEL( _SwCursor_SavePos, 20, 20 )
 /*N*/ }
 
 
-/*N*/ Locale CreateLocale( LanguageType eLanguage )
+/*N*/ Locale CreateLocale( LanguageType /*eLanguage*/ )
 /*N*/ {
-/*?*/ 			DBG_BF_ASSERT(0, "STRIP"); Locale temp; return temp;//STRIP001 	String aLangStr, aCtryStr;
+/*?*/ 			DBG_BF_ASSERT(0, "STRIP"); Locale temp; return temp;
 /*N*/ }
 
 
-- 
1.7.1

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

[Libreoffice] [PATCH 01/16] warning variable unused fix in binfilter bf_sw attr

[Pierre-André Jacquod]

Hi,
here some patches to suppress warnings within binfilter.
I took a - sometimes too - conservative approach for doing this. Hope I
did not harm this module
regards
>From 3c2cd665fe8a344626265f6c8a2a3b195556441d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Sat, 4 Dec 2010 10:18:51 +0100
Subject: [PATCH 01/16] warning variable unused fix in binfilter bf_sw attr

---
 binfilter/bf_sw/source/core/attr/sw_format.cxx |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/binfilter/bf_sw/source/core/attr/sw_format.cxx b/binfilter/bf_sw/source/core/attr/sw_format.cxx
index fdc874a..c424aa3 100644
--- a/binfilter/bf_sw/source/core/attr/sw_format.cxx
+++ b/binfilter/bf_sw/source/core/attr/sw_format.cxx
@@ -213,7 +213,6 @@ namespace binfilter {
 /*N*/ void SwFmt::CopyAttrs( const SwFmt& rFmt, BOOL bReplace )
 /*N*/ {
 /*N*/ 	// kopiere nur das Attribut-Delta Array
-/*N*/ 	register SwCharFmt* pDropCharFmt = 0;
 /*N*/ 
 /*N*/ 	if ( IsInCache() )
 /*N*/ 	{
-- 
1.7.1

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

Re: [Libreoffice] binfilter and features...

[Pierre-André Jacquod]

On 12/05/2010 12:39 PM, Caolán McNamara wrote:

> All true. It was just a note that it might be easier, if you have an
> interest in binfilter, to just take the conservative approach and
> silence warnings with e.g converting

I was thinking of taking a 2 steps approach: first silent warning in a
conservative way (this is also less risk to introduce bugs) and then to
"down-size" the module just keeping the needed part.

In my opinion, the needed part would be, for the next releases, just the
read capability of (older?) binary format build in within LibO.

But if the decision is to drop it anyway for the next release, does not
bring a lot I did not found any inputs about it within mailing
lists. Has the point been discussed somewhere? Is this to be handle by
the steering committee? Is there a "technical" steering committee for
this kind of decision, where we could propose / give reasons for
thinking this or that? Currently, as said, I am doing conservative
warning fixes, but to start something more intrusive, would like to have
first a kind of direction decision.
regards




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

Re: [Libreoffice] binfilter and features...

[Pierre-André Jacquod]

On 12/04/2010 09:49 PM, Caolán McNamara wrote:

> I wouldn't like to see too much effort spent on binfilter though.
I understand the point. On the other side, leting it behind generate a
lot of - not very useful - job when wanting to do global changes, like
the RTL_CONST... macro, or getting ride of old type /  classes,... ?

> at http://people.redhat.com/caolanm/callcatcher/DEV300_m86/ (I cleared
I will have a look at it.

> "desktop" myself recently, I should generate up-to-date lists for
> LibreOffice master)
would be great

>> Which make me think: as new feature, for the next LibO release after
>> 3.3, could it be that StarOffice file format are not supported any more,

>> Or do you intend to drop this in a quicker way?
> 
> A lot of people are of the view to delete the whole thing. I'd prefer to
> move it out of LibreOffice entirely into a standalone project that

As user, I would prefer to still be able to read the file "natively",
even if I can't write / save it anymore. Nothing more boring than having
to search for an add-on... First you have to know it exits, find it,
install it... Far above the average user expectation. I have see a lot
of people getting confused, not able to read a file anymore, simply
going back to the older version, or using afterward another product, not
always noticing they are reading in one format and saving in another one!
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] crossing strange code: a little help

[Pierre-André Jacquod]

Hi
within
filters/binfilter/bf_sw/source/core/txtnode/sw_thints.cxx
line 955, I crossed this code construct:

if()
{
  .
  while (TRUE)
  {
  DBG_BF_ASSERT(0, "STRIP");
  }
  
}

 With and without debugging option on, if the if is entered, then
this is an endless loop? Does it means that the IF is never taken?
thanks
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] binfilter and features...

[Pierre-André Jacquod]

Hi,
currently trying to reduce the number of warning coming from binfilter,
I found quite a lot functions like:
func(var x)
{}
or
func(var x)
{ ASSERT ("lksd")
}.
sometimes
func (var x)
{return false}

Would someone mind if I track down the call of such functions, remove
the calls and at the end remove the function? This would reduce and
simplified the codebase, also more efficient (less function calls) and -
I hope - a smaller LibO.

Of course, these functions are marker, but intend someone really to
developp binfilter ?

Which make me think: as new feature, for the next LibO release after
3.3, could it be that StarOffice file format are not supported any more,
at least in writing modus?. Reading files would open it in read only,
trying to save would produce a warning like "this old format is
deprecated, please save in a new one". Maybe the same for the old OOo
format?

Or do you intend to drop this in a quicker way?

Just for feed-back.
regards
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] making binfilter compiling again

[Pierre-André Jacquod]

Thanks to review and push it quite quickly if possible.
Changes have been done (for RTL_OUSTRING_...) without looking that the
namespace rtl is not declared.
I did not introduced it but just corrected the entries, since I am not
enough familiar to know which is the prefered situation within the project.
regards

>From a70f9654155a6fd17747305afb717471aac92b4c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Fri, 3 Dec 2010 20:39:37 +0100
Subject: [PATCH] making binfilter compiling again

changes for RTL_CONSTASCII_USTRINGPARAM without taking into account
namespaces
---
 binfilter/bf_sfx2/source/config/sfx2_evntconf.cxx  |   14 +++---
 .../bf_sfx2/source/notify/sfx2_eventsupplier.cxx   |6 +++---
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/binfilter/bf_sfx2/source/config/sfx2_evntconf.cxx b/binfilter/bf_sfx2/source/config/sfx2_evntconf.cxx
index b66811f..7f31956 100644
--- a/binfilter/bf_sfx2/source/config/sfx2_evntconf.cxx
+++ b/binfilter/bf_sfx2/source/config/sfx2_evntconf.cxx
@@ -374,13 +374,13 @@ void SfxEventConfigItem_Impl::Init( SfxConfigManager *pMgr )
 /*N*/ OUSTRINGaLib= pMacro->GetLibName();
 /*N*/ OUSTRINGaMacro  = pMacro->GetMacName();
 /*N*/ 
-/*N*/ pValues[ 0 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
+/*N*/ pValues[ 0 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
 /*N*/ pValues[ 0 ].Value <<= aType;
 /*N*/ 
-/*N*/ pValues[ 1 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_LIBRARY ));
+/*N*/ pValues[ 1 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_LIBRARY ));
 /*N*/ pValues[ 1 ].Value <<= aLib;
 /*N*/ 
-/*N*/ pValues[ 2 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
+/*N*/ pValues[ 2 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
 /*N*/ pValues[ 2 ].Value <<= aMacro;
 /*N*/ 
 /*N*/ aEventData <<= aProperties;
@@ -393,10 +393,10 @@ void SfxEventConfigItem_Impl::Init( SfxConfigManager *pMgr )
 /*?*/ OUSTRINGaLib= pMacro->GetLibName();
 /*?*/ OUSTRINGaMacro  = pMacro->GetMacName();
 /*?*/ 
-/*?*/ pValues[ 0 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
+/*?*/ pValues[ 0 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
 /*?*/ pValues[ 0 ].Value <<= aLib;
 /*?*/ 
-/*?*/ pValues[ 1 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_SCRIPT ));
+/*?*/ pValues[ 1 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_SCRIPT ));
 /*?*/ pValues[ 1 ].Value <<= aMacro;
 /*?*/ 
 /*?*/ aEventData <<= aProperties;
@@ -408,10 +408,10 @@ void SfxEventConfigItem_Impl::Init( SfxConfigManager *pMgr )
 /*?*/ 
 /*?*/ OUSTRINGaMacro  = pMacro->GetMacName();
 /*?*/ 
-/*?*/ pValues[ 0 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
+/*?*/ pValues[ 0 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_EVENT_TYPE ));
 /*?*/ pValues[ 0 ].Value <<= ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(SVX_MACRO_LANGUAGE_JAVASCRIPT));
 /*?*/ 
-/*?*/ pValues[ 1 ].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
+/*?*/ pValues[ 1 ].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
 /*?*/ pValues[ 1 ].Value <<= aMacro;
 /*?*/ 
 /*?*/ aEventData <<= aProperties;
diff --git a/binfilter/bf_sfx2/source/notify/sfx2_eventsupplier.cxx b/binfilter/bf_sfx2/source/notify/sfx2_eventsupplier.cxx
index 117b1ef..bdd2134 100644
--- a/binfilter/bf_sfx2/source/notify/sfx2_eventsupplier.cxx
+++ b/binfilter/bf_sfx2/source/notify/sfx2_eventsupplier.cxx
@@ -387,11 +387,11 @@ namespace binfilter {
 aLibrary = sDocument;
 }
 /*N*/ 
-/*N*/ 		aOutProps[1].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_SCRIPT ));
+/*N*/ 		aOutProps[1].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_SCRIPT ));
 /*N*/ 		aOutProps[1].Value <<= aScript;
-/*N*/ 		aOutProps[2].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_LIBRARY ));
+/*N*/ 		aOutProps[2].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_LIBRARY ));
 /*N*/ 		aOutProps[2].Value <<= aLibrary;
-/*N*/ 		aOutProps[3].Name = OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
+/*N*/ 		aOutProps[3].Name = rtl::OUString(RTL_CONSTASCII_USTRINGPARAM( PROP_MACRO_NAME ));
 /*N*/ 		aOutProps[3].Value <<= aMacroName;
 /*N*/ 		rRet <<= aOutProps;
 /*N*/ }
-- 
1.7.1

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

Re: [Libreoffice] Script to find undocumented classes

[Pierre-André Jacquod]

Beware - I am a newcomer - maybe my point of view is quite wrong due to
lack of understanding. But then at least I will understand something
better :- )

My first remark: stepping in seems to me to be very difficult despite
the very friendly behaviour of people here.

> un-documented code-base is an incredibly valuable one - it turns out
> most commercial code-bases are a total mess internally; LibreOffice is
> nothing special. 

Gnap... depend of which software you are speaking, then... For having
(to) read a lot of code in a big software, I can say that
this one (I mean this commercial one) at least is well documented and
quite well written. And no, I do not work for them:- )

> IMHO we cannot and should not put a break on writing that
> just to improve merge-ability, 
Why not drop merging from OOO after LibO 3.3?  As newcomer, I have read
x times "not here due to merge / not touch due to merge"... Then I am
reluctant to touch some parts...At least, the burden should be on side
of person merging OOo into LibO, not be of a concern for people
contributing to LibO.

> enable the re-factoring that can make our APIs both
> pretty and intuitive over time,
I think would very help any newcomer stepping in. Currently hunting
warning, I do it deliberately in order to get used to the code and uses.
But even there, sometimes I skip the point, not being able after
following the function calling the function calling... and determining
for sure that the change would have a cross effect. And I do not even
tried yet to change a feature.
Deliberate choice from me, clear, but yeah...
Regards


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

[Libreoffice] [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)

[Pierre-André Jacquod]

regards

>From f5aac0dd10c586fbcdcd8e6a86e396601db8ad27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Mon, 29 Nov 2010 08:20:37 +0100
Subject: [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)

---
 .../source/core/unocore/sw_SwXTextDefaults.cxx |8 ++--
 binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx  |   17 ---
 binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx |9 ++-
 .../bf_sw/source/core/unocore/sw_unofield.cxx  |   24 ++---
 .../bf_sw/source/core/unocore/sw_unoframe.cxx  |   16 +++---
 binfilter/bf_sw/source/core/unocore/sw_unoftn.cxx  |   16 +++---
 binfilter/bf_sw/source/core/unocore/sw_unoidx.cxx  |   32 +---
 binfilter/bf_sw/source/core/unocore/sw_unoobj.cxx  |   16 +--
 .../bf_sw/source/core/unocore/sw_unorefmk.cxx  |   12 ++--
 binfilter/bf_sw/source/core/unocore/sw_unosect.cxx |   22 +
 binfilter/bf_sw/source/core/unocore/sw_unosett.cxx |   50 +++-
 11 files changed, 133 insertions(+), 89 deletions(-)

diff --git a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
index 14e8028..c1acdb5 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
@@ -166,28 +166,28 @@ Any SAL_CALL SwXTextDefaults::getPropertyValue( const OUString& rPropertyName )
 }
 
 
-void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& xListener )
+void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*xListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
index 98d174d..fead095 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
@@ -275,7 +275,7 @@ uno::Reference< beans::XPropertySetInfo >  SwXBookmark::getPropertySetInfo(void)
 return aRef;
 }
 
-void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& aValue)
+void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& /*aValue*/)
 throw( beans::UnknownPropertyException, beans::PropertyVetoException,
 lang::IllegalArgumentException, lang::WrappedTargetException, uno::RuntimeException )
 {
@@ -294,25 +294,26 @@ uno::Any SwXBookmark::getPropertyValue(const OUString& rPropertyName) throw( bea
 return aRet;
 }
 
-void SwXBookmark::addPropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::addPropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
 throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
 {
 }
 
-void SwXBookmark::removePropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::removePropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
 throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
 {
 }
 
-void SwXBookmark::addVetoableChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::X

[Libreoffice] [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)

[Pierre-André Jacquod]

regards

>From f5aac0dd10c586fbcdcd8e6a86e396601db8ad27 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Mon, 29 Nov 2010 08:20:37 +0100
Subject: [PATCH 4/5] trivial warning cleaning in binfilter - unocore (1)

---
 .../source/core/unocore/sw_SwXTextDefaults.cxx |8 ++--
 binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx  |   17 ---
 binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx |9 ++-
 .../bf_sw/source/core/unocore/sw_unofield.cxx  |   24 ++---
 .../bf_sw/source/core/unocore/sw_unoframe.cxx  |   16 +++---
 binfilter/bf_sw/source/core/unocore/sw_unoftn.cxx  |   16 +++---
 binfilter/bf_sw/source/core/unocore/sw_unoidx.cxx  |   32 +---
 binfilter/bf_sw/source/core/unocore/sw_unoobj.cxx  |   16 +--
 .../bf_sw/source/core/unocore/sw_unorefmk.cxx  |   12 ++--
 binfilter/bf_sw/source/core/unocore/sw_unosect.cxx |   22 +
 binfilter/bf_sw/source/core/unocore/sw_unosett.cxx |   50 +++-
 11 files changed, 133 insertions(+), 89 deletions(-)

diff --git a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
index 14e8028..c1acdb5 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_SwXTextDefaults.cxx
@@ -166,28 +166,28 @@ Any SAL_CALL SwXTextDefaults::getPropertyValue( const OUString& rPropertyName )
 }
 
 
-void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& xListener )
+void SAL_CALL SwXTextDefaults::addPropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*xListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& rPropertyName, const Reference< XPropertyChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removePropertyChangeListener( const OUString& /*rPropertyName*/, const Reference< XPropertyChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::addVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
 }
 
 
-void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& rPropertyName, const Reference< XVetoableChangeListener >& aListener )
+void SAL_CALL SwXTextDefaults::removeVetoableChangeListener( const OUString& /*rPropertyName*/, const Reference< XVetoableChangeListener >& /*aListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING ( "not implemented" );
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
index 98d174d..fead095 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unobkm.cxx
@@ -275,7 +275,7 @@ uno::Reference< beans::XPropertySetInfo >  SwXBookmark::getPropertySetInfo(void)
 return aRef;
 }
 
-void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& aValue)
+void SwXBookmark::setPropertyValue(const OUString& PropertyName, const uno::Any& /*aValue*/)
 throw( beans::UnknownPropertyException, beans::PropertyVetoException,
 lang::IllegalArgumentException, lang::WrappedTargetException, uno::RuntimeException )
 {
@@ -294,25 +294,26 @@ uno::Any SwXBookmark::getPropertyValue(const OUString& rPropertyName) throw( bea
 return aRet;
 }
 
-void SwXBookmark::addPropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::addPropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
 throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
 {
 }
 
-void SwXBookmark::removePropertyChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::XPropertyChangeListener > & aListener)
+void SwXBookmark::removePropertyChangeListener(const OUString& /*PropertyName*/,
+const uno::Reference< beans::XPropertyChangeListener > & /*aListener*/)
 throw( beans::UnknownPropertyException, lang::WrappedTargetException, uno::RuntimeException )
 {
 }
 
-void SwXBookmark::addVetoableChangeListener(const OUString& PropertyName,
-const uno::Reference< beans::X

[Libreoffice] [PATCH 5/5] trivial warning cleaning in binfilter - unocore (2)

[Pierre-André Jacquod]

regards
>From 09642903881c193ff01f2801461dcddeae0931ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= 
Date: Mon, 29 Nov 2010 22:13:22 +0100
Subject: [PATCH 5/5] trivial warning cleaning in binfilter - unocore (2)

---
 binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx |   12 ++-
 binfilter/bf_sw/source/core/unocore/sw_unomap.cxx  |   11 +--
 binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx |8 +-
 .../bf_sw/source/core/unocore/sw_unoparagraph.cxx  |   27 ---
 binfilter/bf_sw/source/core/unocore/sw_unoport.cxx |   32 ---
 .../bf_sw/source/core/unocore/sw_unoredline.cxx|   12 ++--
 .../bf_sw/source/core/unocore/sw_unoredlines.cxx   |4 +-
 binfilter/bf_sw/source/core/unocore/sw_unosrch.cxx |   16 +++-
 .../bf_sw/source/core/unocore/sw_unostyle.cxx  |   26 +++---
 binfilter/bf_sw/source/core/unocore/sw_unotbl.cxx  |   90 ++--
 binfilter/bf_sw/source/core/unocore/sw_unotext.cxx |   18 ++--
 11 files changed, 155 insertions(+), 101 deletions(-)

diff --git a/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx b/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
index 5533ee5..37cb25e 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unodraw.cxx
@@ -1285,27 +1285,29 @@ Any SwXShape::getPropertyDefault( const OUString& rPropertyName )
 return aRet;
 }
 
-void SwXShape::addPropertyChangeListener(const OUString& /*PropertyName*/, const Reference< XPropertyChangeListener > & /*aListener*/) 
+void SwXShape::addPropertyChangeListener(const OUString& /*PropertyName*/,
+const Reference< XPropertyChangeListener > & /*aListener*/)
 throw( UnknownPropertyException, WrappedTargetException, RuntimeException )
 {
 DBG_WARNING("not implemented");
 }
 
 void SwXShape::removePropertyChangeListener(
-const OUString& PropertyName,
-const Reference< XPropertyChangeListener > & aListener)
+const OUString& /*PropertyName*/,const Reference< XPropertyChangeListener > & /*aListener*/)
 throw( UnknownPropertyException, WrappedTargetException, RuntimeException )
 {
 DBG_WARNING("not implemented");
 }
 
-void SwXShape::addVetoableChangeListener(const OUString& /*PropertyName*/, const Reference< XVetoableChangeListener > & /*aListener*/) 
+void SwXShape::addVetoableChangeListener(
+const OUString& /*PropertyName*/, const Reference< XVetoableChangeListener > & /*aListener*/)
 throw( UnknownPropertyException, WrappedTargetException, RuntimeException )
 {
 DBG_WARNING("not implemented");
 }
 
-void SwXShape::removeVetoableChangeListener(const OUString& /*PropertyName*/, const Reference< XVetoableChangeListener > & /*aListener*/) 
+void SwXShape::removeVetoableChangeListener(const OUString& /*PropertyName*/,
+const Reference< XVetoableChangeListener > & /*aListener*/)
 throw( UnknownPropertyException, WrappedTargetException, RuntimeException )
 {
 DBG_WARNING("not implemented");
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unomap.cxx b/binfilter/bf_sw/source/core/unocore/sw_unomap.cxx
index 0d0fd71..1a46a94 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unomap.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unomap.cxx
@@ -2321,17 +2321,10 @@ const SfxItemPropertyMap* SwUnoPropertyMapProvider::GetPropertyMap(sal_uInt16 nP
 }
 return aMapArr[nPropertyId];
 }
-/* -04.07.98 11:42---
- *
- * --*/
-sal_Bool SwItemPropertySet::FillItem(SfxItemSet& rSet, sal_uInt16 nWhich, sal_Bool bGetProperty) const
+
+sal_Bool SwItemPropertySet::FillItem(SfxItemSet& /*rSet*/, sal_uInt16 /*nWhich*/, sal_Bool /*bGetProperty*/) const
 {
 sal_Bool bRet = sal_False;
-/*	if(nWhich == SID_ATTR_PAGE_PAPERBIN)
-{
-rSet.Put(SvxPaperBinItem(SID_ATTR_PAGE_PAPERBIN, 0));
-bRet = sal_True;
-}*/
 return bRet;
 }
 }
diff --git a/binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx b/binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx
index 81ba642..4a88ebc 100644
--- a/binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx
+++ b/binfilter/bf_sw/source/core/unocore/sw_unoobj2.cxx
@@ -1934,7 +1934,7 @@ Any SAL_CALL SwXTextRange::getPropertyValue( const OUString& rPropertyName )
 
   ---*/
 void SAL_CALL SwXTextRange::addPropertyChangeListener(
-const OUString& aPropertyName, const Reference< XPropertyChangeListener >& xListener )
+const OUString& /*aPropertyName*/, const Reference< XPropertyChangeListener >& /*xListener*/ )
 throw(UnknownPropertyException, WrappedTargetException, RuntimeException)
 {
 DBG_WARNING("not implemented");
@@ -1943,7 +1943,7 @@ void SAL_CALL SwXTextRange::addPropertyChangeListener(
 
   ---*/
 void SAL_CALL SwXTextRange::removePropertyChangeListener(
-const OUString& aPropertyName, co