LibreOffice problems

[smbhatt]

Dear Sir,
 We have started using LibreOffice 4.1.1 suite and have encountered
several problems. Please help.
 1. If we open Email attachment (.xls file) directly in Libre Calc
(through file association) it will open as read only. While the same if
opened in MS Excel it opens to a temp folder from where it can be 'Save
As' to folder of choice and the file in temp is deleted. In Librecalc, I
first have to 'Save As' to a folder, open it through Win Explorer.
 2. Filter: Filter By colour not supported.
 3. Print Quality is different in MS Excel Vs Libre Office.
 4. 'Page No' By default display in print page and there is no option to
not display by default. For each sheet you have to set the footer
manually.
 5. Problem when we open MS Excel file with cell borders to LibreCalc.  
6. In Writer the page formatting (where there are graphics, tables etc.)
made in Word, gets lost along with the contents and entire Word document
gets disturbed. Very poor quality of document is available.   7. In
Impress same problem as 6 happens. Titles gets heavily disturbed
(misplaced), Simple graphics (which has no relevance to slide format) like
small images gets lost and so does the text, also the text colour changes.
A suggestion is  that id the font is not supported, atleast display the
windows default or the default font could be set in 'Options').
 We are grateful for providing such valuable Office Suite but it appears
that LibreOffice is more suitable only for replacing MS Excel and other
Suite products cannot be used as they loose valuable information in
conversion.
Please reply to the above email id.
 Thanks and Regards
-

Er. Shirish M Bhatt
Dy. Manager, HO-ISD
Gujarat Cooperative Milk Marketing Federation Ltd.
Amul Dairy Road P B No.10,
Anand 388 001, Gujarat, India
Phone: +91-2692-221261(O), 93750-32277(M)
The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressees)and
may contain proprietary, confidential or privileged  information. If you
are not the intended recipient, you should not disseminate, distribute or
copy this email.  Please notify the sender immediately and destroy all
copies of this message and any attachments. Opinions, conclusions, and
other information in this message that  do not relate to the official
business of GCMMF Ltd. shall be understood to be neither given nor
endorsed by GCMMF Ltd.

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no  liability for any damage caused by any virus
transmitted by this email.

GO GREEN: Please don't print this e-mail unless you really need to.


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

Re: LibreOffice problems

[bjoern]

Hi,

On Sat, Sep 14, 2013 at 11:48:50AM +0530, smbhatt wrote:
>  We have started using LibreOffice 4.1.1 suite and have encountered
> several problems. Please help.

this list is for LibreOffice code and bugfixing. User-to-User support can be
found at:

 us...@global.libreoffice.org
 http://nabble.documentfoundation.org/Users-f1639498.html

or at:

 http://ask.libreoffice.org/en/questions/

Thanks for your understanding!

Best,

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

Re: LibreOffice problems

[Arno Teigseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/14/2013 08:18 AM, smbhatt wrote:
> We have started using LibreOffice 4.1.1 suite and have encountered 
> several problems. Please help.
> 
> 1. If we open Email attachment (.xls file) directly in Libre Calc 
> (through file association) it will open as read only.
If the file is an email attachment, LO probably won't have write access.
Would it help clicking the "Edit" button? It's one similar to this image

http://aveesplace.files.wordpress.com/2011/04/libreoffice-readonly.png?w=630

> 4. 'Page No' By default display in print page and there is no
> option to not display by default. For each sheet you have to set
> the footer
manually.
If you remove header and footer from a sheet (Format - Page) and add
new sheet, it should

You can save this as a template and specify it as default template, if
you want header/footer off by default

> 6. In Writer the page formatting (where there are graphics, tables 
> etc.) made in Word, gets lost along with the contents and entire
> Word document gets disturbed. Very poor quality of document is
> available.
Do you have same fonts installed on both machines?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlI7SXcACgkQEMIGVCc8BjBtsACfetK2uXSCZP8vSfdNDe5NIc7z
5SgAoKVuLCsJWyQU8848LzEVZaxbeAzC
=912n
-END PGP SIGNATURE-
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] problems building basic

[Christina Roßmanith]

Hi,

I did a "./g pull -r" yesterday (Saturday). After applying patches I'd 
like to build basic. It fails with


/bin/bash: /Amanda/LibreOffice3/libo/solver/300/unxlngi6.pro/bin/rscdep: 
No such file or directory


The error message is correct, but instead there is 
/Amanda/LibreOffice3/libo/solver/330/unxlngi6.pro/bin/rscdep. Note 330 
instead of 300. What has to be changed that the correct directory is used?


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

[Libreoffice] problems with scp2

[Matúš Kukan]

Hi all,

I have tried to move salhelper to new build system and it builds nice
(for me) but there is problem with scp2.
In old system we were creating libuno_salhelpergcc3.so.3 and
libuno_salhelpergcc3.so was just link to it.

So now I'm getting: ERROR: File not found: libuno_salhelpergcc3.so.3
from smoketestoo_native because now is created only libuno_salhelpergcc3.so.

So, I'm not sure about solution. Somehow change scp2 or create both
files or just the one with .3.

Thanks,
Matus

Ps: I tried to create just libuno_salhelpergcc3.so.3 but that does not
want to work, not sure why.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Problems with Windows build

[Jeremy Brown]

I'm trying to build on Windows Vista, following the directions at:

http://wiki.documentfoundation.org/Development/Native_Build#Partial_build
and
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies

When I run make for the first time, I get to a point where it tells me there
are possibly problems in libxml2, lpsolve, curl, or openssl.

The development wiki tells me I should issue commands like:
$ source *Env.Set.sh
$ cd libxml2
$ rm - r $INPATH ; deliver -delete
$ build

But those commands give me errors like these below:
$ source *Env.Set.sh
bash: *Env.Set.sh: No such file or directory

$ cd libxml2

$ rm -r $INPATH ; deliver -delete
rm: missing operand
Try `rm --help' for more information.
bash: deliver: command not found

$ build
bash: build: command not found

Could anyone give me any suggestions of Windows/Cygwin-specific commands I
should be using to build modules that report errors?

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

[Libreoffice] problems with component registration

[Noel Power]

Hi David,

It seems that 
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=f9496177a4c942f2acc39a978a3cd65689f14d8d 
is causing some problems with component registration with at least basic 
on master. I have a temporary fix for this here 
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=1aa0150844d37e28cf0b420cbc60a96ad478edbe. 
The problem stems from the fact the legacy code (now) needs 
OModule.registerClient to be  called. However that call is never made. 
I'm not familiar with these helper classes so I am hoping you might know 
how the register/revoke client stuff should work ( and who/when/where 
should call what )
My main worry though is that perhaps this changes breaks more than 
basic. so... in the mean time it might be worth considering backing out 
that change



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

Re: [Libreoffice] problems with scp2

[Bjoern Michaelsen]

Hi Matúš, all,
On Fri, 29 Jul 2011 12:46:43 +0200
Matúš Kukan  wrote:


> I have tried to move salhelper to new build system and it builds nice
> (for me) but there is problem with scp2.
> In old system we were creating libuno_salhelpergcc3.so.3 and
> libuno_salhelpergcc3.so was just link to it.
> 
> So now I'm getting: ERROR: File not found: libuno_salhelpergcc3.so.3
> from smoketestoo_native because now is created only
> libuno_salhelpergcc3.so.
> 
> So, I'm not sure about solution. Somehow change scp2 or create both
> files or just the one with .3.

So my question about this: do we really want this versioned lib symlink
foo in solver, or do we rather have such stuff in the installation only
(i.e. generated in for example scp2). The only clients for the libs in
the solver are linking and our unittests, which can get along nicely
without the versioning, right? OTOH we might want to have a "runnable
solver" i.e. recreating the installation in a runnable state in solver
one day, and them we would need this anyway.

We could create a OutdirSymlinkTarget in gbuild quite easily for that,
but is that the right thing to do? After all this is also highly
platformdependant, and IMHO such things shouldnt bother the random
hacker working in salhelper at all (it should be dark magic done during
the install step.

Opinions?

Best,

Bjoern


-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] problems with scp2

[Stephan Bergmann]

On 29.07.2011, at 12:57, Bjoern Michaelsen  
wrote:
> Hi Matúš, all,
> On Fri, 29 Jul 2011 12:46:43 +0200
> Matúš Kukan  wrote:
> 
> 
>> I have tried to move salhelper to new build system and it builds nice
>> (for me) but there is problem with scp2.
>> In old system we were creating libuno_salhelpergcc3.so.3 and
>> libuno_salhelpergcc3.so was just link to it.
>> 
>> So now I'm getting: ERROR: File not found: libuno_salhelpergcc3.so.3
>> from smoketestoo_native because now is created only
>> libuno_salhelpergcc3.so.
>> 
>> So, I'm not sure about solution. Somehow change scp2 or create both
>> files or just the one with .3.
> 
> So my question about this: do we really want this versioned lib symlink
> foo in solver, or do we rather have such stuff in the installation only
> (i.e. generated in for example scp2). The only clients for the libs in
> the solver are linking and our unittests, which can get along nicely
> without the versioning, right?

No. While linking wants the unversioned libFOO.so (thanks to passing them as 
-lFOO to the linker), running the unit tests wants the versioned libFOO.so.3 
(thanks to the SONAME).

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

Re: [Libreoffice] problems with scp2

[Bjoern Michaelsen]

Hi Stephan,

On Sat, 30 Jul 2011 10:45:03 +0200
Stephan Bergmann

wrote:

> No. While linking wants the unversioned libFOO.so (thanks to passing
> them as -lFOO to the linker), running the unit tests wants the
> versioned libFOO.so.3 (thanks to the SONAME).

Im glad to have told Matúš to put this on the ML, it deserves a more
thorough investigation. ;)

Well, since gbuild as of now has no notion of versioned SONAMES or
filenames(1), I assume the Matúš-migrated salhelper module would create
a lib with name libuno_salhelpergcc3.so and no explicit SONAME (since no
--soname switches are used). "readelf -a| grep SONAME" on it would
return nothing. Given that, every library linked against that lib (in a
BFS) would link against the (fallback) unversioned filename, and that
would work fine in the build and out of it.

Using such a lib in the solver should not be a problem for the build.
However, even if it would be easily possible to add the SONAME upon
installation, it would be quite an ugly hack. So does it hurt to have
unversioned/missing SONAMEs in the installation?

Well, if we would symlink in the installation as before, old
external clients wouldnt be hurt, as they still find their libs. But
newly created external libraries would be created linking against an
unversioned/missing SONAME (because they would fall back to the resolved
filename). Would that hurt? Right now, from a practical point of view,
I guess: no. No linux distro supports installing different versions of
the product, let alone from different major releases. So if I am not
mistaken, the benefit of versioned SONAMEs -- while being the Right
Thing(tm) -- are mostly theoretical as of now.

Of course, the magic is all in the words "as of now" -- requirements
might change. 

Oh, and btw: welcome and nice to have your comments on this list!

Best,

Bjoern


(1) $(call gb_Library_get_filename,salhelper) returns
libuno_salhelpergcc3.so

-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] problems with scp2

[Stephan Bergmann]

On Jul 31, 2011, at 12:32 AM, Bjoern Michaelsen wrote:
> On Sat, 30 Jul 2011 10:45:03 +0200
> Stephan Bergmann
> 
> wrote:
> 
>> No. While linking wants the unversioned libFOO.so (thanks to passing
>> them as -lFOO to the linker), running the unit tests wants the
>> versioned libFOO.so.3 (thanks to the SONAME).
> 
> Im glad to have told Matúš to put this on the ML, it deserves a more
> thorough investigation. ;)
> 
> Well, since gbuild as of now has no notion of versioned SONAMES or
> filenames(1), I assume the Matúš-migrated salhelper module would create
> a lib with name libuno_salhelpergcc3.so and no explicit SONAME (since no
> --soname switches are used). "readelf -a| grep SONAME" on it would
> return nothing. Given that, every library linked against that lib (in a
> BFS) would link against the (fallback) unversioned filename, and that
> would work fine in the build and out of it.

Hi Björn.

What do you mean with "BFS" here?

Generally, existing code (i.e., extensions) having a recorded dependency 
against libuno_salhelpergcc3.so.3 will no longer work if they do not find a 
file with that exact name.  (Or do you imply that, on Linux, the dynamic loader 
special cases this and would still be happy if it only found some 
libuno_salhelpergcc3.so?  I am not aware of that, and it would be Linux-only, 
probably not working on e.g. Solaris.)

> Using such a lib in the solver should not be a problem for the build.
> However, even if it would be easily possible to add the SONAME upon
> installation, it would be quite an ugly hack. So does it hurt to have
> unversioned/missing SONAMEs in the installation?

I strongly suggest to add SONAME support to gbuild.  For one, it is common ELF 
practice to use external versioning (i.e., via a trailing .so.X at a library's 
filename/SONAME) to discriminate among incompatible versions of a library.  And 
for another, we already use that external versioning scheme for the libraries 
that comprise the URE interface, and I see no reason to change that (causing 
incompatibility with existing code).

> Well, if we would symlink in the installation as before, old
> external clients wouldnt be hurt, as they still find their libs. But
> newly created external libraries would be created linking against an
> unversioned/missing SONAME (because they would fall back to the resolved
> filename). Would that hurt? Right now, from a practical point of view,
> I guess: no. No linux distro supports installing different versions of
> the product, let alone from different major releases. So if I am not
> mistaken, the benefit of versioned SONAMEs -- while being the Right
> Thing(tm) -- are mostly theoretical as of now.
> 
> Of course, the magic is all in the words "as of now" -- requirements
> might change. 

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

Re: [Libreoffice] problems with scp2

[Bjoern Michaelsen]

Hi Stephan,

On Mon, 1 Aug 2011 08:42:21 +0200
Stephan Bergmann

wrote:
> What do you mean with "BFS" here?

"build from scratch"

> Generally, existing code (i.e., extensions) having a recorded
> dependency against libuno_salhelpergcc3.so.3 will no longer work if
> they do not find a file with that exact name.

Right, but extensions would not be run against the solver, but against
an installation (where I suggested one needs to keep symlinks anyway).
The suggestion was:
- keep no SONAME or libuno_salhelpergcc3.so (unversioned) in solver and
  installation
- still generate symlinks in installation so that in a installation
  (but not in solver), both libuno_salhelpergcc3.so and
  libuno_salhelpergcc3.so.3 are visible.

> (Or do you imply that,
> on Linux, the dynamic loader special cases this and would still be
> happy if it only found some libuno_salhelpergcc3.so?  I am not aware
> of that, and it would be Linux-only, probably not working on e.g.
> Solaris.)

no.

> I strongly suggest to add SONAME support to gbuild.  For one, it is
> common ELF practice to use external versioning (i.e., via a
> trailing .so.X at a library's filename/SONAME) to discriminate among
> incompatible versions of a library.

I came to the same conclusion: While the other scenario might work, it
will end up like a evil genius dialog in the end: "But why did you do
this?" -- "Because I can!". Thats not a good reason in itself.

But maybe even the symlinks do not need to be manually declared and
created in solver. To follow the conventions of the host system calling
"ldconfig -n $OUTDIR/lib" after installing and before using the
lib should be enough. However, experimenting with this does not seem to
create an unversioned symlink. I created a dir with a few random libs:
libxml2.so.2.7.8 (SONAME:libxml2.so.2)
libcairo.so.2.11000.2 (SONAME: libcairo.so.2)
libuno_salhelpergcc3.so.3 (SONAME: libuno_salhelpergcc3.so.3)
and got:
libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so.3
libxml2.so.2 -> libxml2.so.2.7.8
libcairo.so.2 -> libcairo.so.2.11000.2
so it does not create symlinks for the unversioned so (although those
are quite common in /usr/lib here).
For fun I move the lib libuno_salhelpergcc3.so.3 to
libuno_salhelpergcc3.so and got:
libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so (changed)
libxml2.so.2 -> libxml2.so.2.7.8
libcairo.so.2 -> libcairo.so.2.11000.2
Which does not make me happy either. So I guess we need to create the
symlinks (at least the unversioned ones) manually indeed.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] problems with scp2

[Stephan Bergmann]

On Aug 1, 2011, at 10:02 AM, Bjoern Michaelsen wrote:
> On Mon, 1 Aug 2011 08:42:21 +0200
> Stephan Bergmann
> 
> wrote:
>> Generally, existing code (i.e., extensions) having a recorded
>> dependency against libuno_salhelpergcc3.so.3 will no longer work if
>> they do not find a file with that exact name.
> 
> Right, but extensions would not be run against the solver, but against
> an installation (where I suggested one needs to keep symlinks anyway).
> The suggestion was:
> - keep no SONAME or libuno_salhelpergcc3.so (unversioned) in solver and
>  installation
> - still generate symlinks in installation so that in a installation
>  (but not in solver), both libuno_salhelpergcc3.so and
>  libuno_salhelpergcc3.so.3 are visible.

OK, I see.

>> I strongly suggest to add SONAME support to gbuild.  For one, it is
>> common ELF practice to use external versioning (i.e., via a
>> trailing .so.X at a library's filename/SONAME) to discriminate among
>> incompatible versions of a library.
> 
> I came to the same conclusion: While the other scenario might work, it
> will end up like a evil genius dialog in the end: "But why did you do
> this?" -- "Because I can!". Thats not a good reason in itself.
> 
> But maybe even the symlinks do not need to be manually declared and
> created in solver. To follow the conventions of the host system calling
> "ldconfig -n $OUTDIR/lib" after installing and before using the
> lib should be enough. However, experimenting with this does not seem to
> create an unversioned symlink. I created a dir with a few random libs:
>   libxml2.so.2.7.8 (SONAME:libxml2.so.2)
>   libcairo.so.2.11000.2 (SONAME: libcairo.so.2)
>   libuno_salhelpergcc3.so.3 (SONAME: libuno_salhelpergcc3.so.3)
> and got:
>   libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so.3
>   libxml2.so.2 -> libxml2.so.2.7.8
>   libcairo.so.2 -> libcairo.so.2.11000.2
> so it does not create symlinks for the unversioned so (although those
> are quite common in /usr/lib here).
> For fun I move the lib libuno_salhelpergcc3.so.3 to
> libuno_salhelpergcc3.so and got:
>   libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so (changed)
>   libxml2.so.2 -> libxml2.so.2.7.8
>   libcairo.so.2 -> libcairo.so.2.11000.2
> Which does not make me happy either. So I guess we need to create the
> symlinks (at least the unversioned ones) manually indeed.

And I would create the symlinks in the solver explicitly, anyway, not via 
ldconfig.  ldconfig is imprecise, in that it takes a whole directory as input; 
and you would want to be able to link against a lib as soon as it is built, so 
would call ldconfig multiple times on $OUTDIR/lib (right?), which sounds like a 
bad idea in a parallel build.

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

Re: [Libreoffice] problems with scp2

[Bjoern Michaelsen]

On Mon, 1 Aug 2011 12:56:32 +0200
Stephan Bergmann

wrote:

> And I would create the symlinks in the solver explicitly, anyway, not
> via ldconfig.  ldconfig is imprecise, in that it takes a whole
> directory as input; and you would want to be able to link against a
> lib as soon as it is built, so would call ldconfig multiple times on
> $OUTDIR/lib (right?), which sounds like a bad idea in a parallel
> build.

Well, there is "ldconfig -l" with would prevent the parallelization
problems, but as we need manual symlinks for the unversioned link
anyway, I think thats moot.

Best, Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] problems with scp2

[Bjoern Michaelsen]

Hi Matúš,

On Fri, 29 Jul 2011 12:46:43 +0200
Matúš Kukan  wrote:

> So, I'm not sure about solution. Somehow change scp2 or create both
> files or just the one with .3.

I think I have an idea on how to solve this. I would suggest you to
push you salhelper work to a featurebranch "feature/gbuild_salhelper"
right after the OneGit-migration finished. I will tune gbuild to handle
the scenario there and then we can integrate it into master.

Best,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen


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

Re: [Libreoffice] Problems with windows build

[Steven Butler]

> Hi Steven,
>
> Have you tried "--enable-graphite=no"? That ought to work.
>

I ended up reenabling graphite and setting the stdext to be std, and
commenting out the namespace alias.

That made it work for that.  I have a couple of modules that are still
failing to build.  I'll re-fetch and try again.

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

Re: [Libreoffice] Problems with windows build

[Steven Butler]

On 4 February 2011 22:25, Steven Butler  wrote:
> I ended up reenabling graphite and setting the stdext to be std, and
> commenting out the namespace alias.

I'm getting a lot further into the build now, but have encountered a
problem with what looks like dotnet bindings?

I keep getting climaker.exe has stopped working popups.

And after a while of dismissing these, saxparser goes into an infinite loop.

This is in the cli_ure module.

Does anyone have any ideas... I've had enough for tonight.

Entering /home/Steve/libre/libo/cli_ure/unotypes

: && PATH=${PATH+${PATH}:}/home/Steve/libre/libo/solver/330/wntmsci12.pro/bi
n ../wntmsci12.pro/bin/climaker  \
--out ../wntmsci12.pro/bin/cli_uretypes.dll \
--keyfile ../wntmsci12.pro/bin/cliuno.snk \
--assembly-version 1.0.7.0 \
--assembly-description "This assembly contains metadata for the StarOffi
ce/OpenOffice.org API." \
--assembly-company "OpenOffice.org" \
C:/cygwin/home/Steve/libre/libo/solver/330/wntmsci12.pro/bin/udkapi.rdb

> error: .NET exception occurred: System.AccessViolationException: Attempted to
read or write protected memory. This is often an indication that other memory is
 corrupt.
   at cppu.bootstrap_InitialComponentContext(Reference* , Reference* , OUStri
ng* )
   at ?A0x04292f9a.sal_main()
> dying abnormally...
-- 
Regards,
Steven Butler
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Jesús Corrius]

On Fri, Feb 4, 2011 at 2:18 PM, Steven Butler  wrote:
> On 4 February 2011 22:25, Steven Butler  wrote:
>> I ended up reenabling graphite and setting the stdext to be std, and
>> commenting out the namespace alias.
>
> I'm getting a lot further into the build now, but have encountered a
> problem with what looks like dotnet bindings?
>
> I keep getting climaker.exe has stopped working popups.
>
> And after a while of dismissing these, saxparser goes into an infinite loop.
>
> This is in the cli_ure module.

If you are building it with Visual Studio 2010, it's a known and
unfortunate issue.
I was working to fix it in my old computer, but that computer died and
I only had a copy of Visual Studio 2008 Professional in DVD so I
installed this one.

-- 
Jesús Corrius 
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Tor Lillqvist]

> And after a while of dismissing these, saxparser goes into an infinite loop.

For me, saxparser crashes... I am debugging that but not really getting much 
wiser. The crash happens in typelib_typedescription_newMIInterface() in 
cppu/source/typelib; it seems that the call to 
typelib_typedescriptionreference_new() on line 1236 modifies what the iterator 
i is iterating so that i points to some bogus data and 
i->directBaseMemberOffset is a totally bogus and then the next round in the 
enclosing for loop on line 1226 the indexing crashes.

--tml


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

Re: [Libreoffice] Problems with windows build

[Caolán McNamara]

On Fri, 2011-02-04 at 06:41 -0700, Tor Lillqvist wrote:
> > And after a while of dismissing these, saxparser goes into an infinite loop.
> 
> For me, saxparser crashes... I am debugging that but not really getting much 
> wiser.

does this patch, to revert a hash_map -> unordered_map make it "go away"

C.
diff --git a/cppu/source/uno/EnvStack.cxx b/cppu/source/uno/EnvStack.cxx
index c96d307..99322eb 100644
--- a/cppu/source/uno/EnvStack.cxx
+++ b/cppu/source/uno/EnvStack.cxx
@@ -36,7 +36,7 @@
 #include "osl/thread.h"
 #include "osl/mutex.hxx"
 
-#include 
+#include 
 
 
 using namespace com::sun::star;
@@ -65,7 +65,7 @@ size_t oslThreadIdentifier_hash::operator()(oslThreadIdentifier s1) const
 return s1;
 }
 
-typedef ::boost::unordered_map  ThreadMap;
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Thomas Arnhold]

I think the problem is, that without resize the hash map could be
overfilled.

I did fix this like commit 6ecdae26517b89ee670.

Think problem is like in PspKernInfo::Initialize() [in
vcl/unx/source/gdi/salgdi3.cxx]:

maUnicodeKernPairs.insert( aKernPair );

maUnicodeKernPairs is boost::unordered_map  and rKernPairs is std::list.
Is it clean to do this?! And: If we don't resize maUnicodeKernPairs to
the size of aKernPair, could we run out of memory - this would be the
case for all of them?

Thomas

On 02/04/2011 08:17 PM, Caolán McNamara wrote:
> On Fri, 2011-02-04 at 06:41 -0700, Tor Lillqvist wrote:
>>> And after a while of dismissing these, saxparser goes into an infinite loop.
>>
>> For me, saxparser crashes... I am debugging that but not really getting much 
>> wiser.
> 
> does this patch, to revert a hash_map -> unordered_map make it "go away"
> 
> C.
> 
> 
> 
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

diff --git a/vcl/source/gdi/configsettings.cxx 
b/vcl/source/gdi/configsettings.cxx
index 0b1dcbb..ac38d23 100644
--- a/vcl/source/gdi/configsettings.cxx
+++ b/vcl/source/gdi/configsettings.cxx
@@ -134,7 +134,6 @@ void SettingsConfigItem::getValues()
 m_aSettings.clear();
 
 Sequence< OUString > aNames( GetNodeNames( OUString() ) );
-m_aSettings.resize( aNames.getLength() );
 
 for( int j = 0; j < aNames.getLength(); j++ )
 {
diff --git a/vcl/unx/headless/svptext.cxx b/vcl/unx/headless/svptext.cxx
index 8701a7f..1523241 100644
--- a/vcl/unx/headless/svptext.cxx
+++ b/vcl/unx/headless/svptext.cxx
@@ -194,7 +194,6 @@ void PspKernInfo::Initialize() const
 return;
 
 // feed psprint's kerning list into a lookup-friendly container
-maUnicodeKernPairs.resize( rKernPairs.size() );
 PspKernPairs::const_iterator it = rKernPairs.begin();
 for(; it != rKernPairs.end(); ++it )
 {
diff --git a/vcl/unx/source/gdi/salgdi3.cxx b/vcl/unx/source/gdi/salgdi3.cxx
index d3718f5..50283ff 100644
--- a/vcl/unx/source/gdi/salgdi3.cxx
+++ b/vcl/unx/source/gdi/salgdi3.cxx
@@ -523,7 +523,6 @@ void PspKernInfo::Initialize() const
 return;
 
 // feed psprint's kerning list into a lookup-friendly container
-maUnicodeKernPairs.resize( rKernPairs.size() );
 PspKernPairs::const_iterator it = rKernPairs.begin();
 for(; it != rKernPairs.end(); ++it )
 {
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Jesús Corrius]

On Fri, Feb 4, 2011 at 8:17 PM, Caolán McNamara  wrote:
> On Fri, 2011-02-04 at 06:41 -0700, Tor Lillqvist wrote:
>> > And after a while of dismissing these, saxparser goes into an infinite 
>> > loop.
>>
>> For me, saxparser crashes... I am debugging that but not really getting much 
>> wiser.
>
> does this patch, to revert a hash_map -> unordered_map make it "go away"

If this helps, on Windows in debug I am getting this:

Assertion failed: r != end(), file
C:\libod\solver\330\wntmsci12\inc\boost/unordered/detail/hash_table_impl.hpp,
line 890

-- 
Jesús Corrius 
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Steven Butler]

Hi,


2011/2/4 Jesús Corrius :
> On Fri, Feb 4, 2011 at 2:18 PM, Steven Butler  wrote:
>> I keep getting climaker.exe has stopped working popups.

> If you are building it with Visual Studio 2010, it's a known and
> unfortunate issue.


I just realised I have VS2010 Express and vs2008 Express C# editions
installed.  It could well be using the vs2010 instance for C#.

I only have VS2008 Express C++ edition installed.  How much effort is
likely required to get it working with 2010, or should I just work on
getting it to use 2008?

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

Re: [Libreoffice] Problems with windows build

[Jesús Corrius]

> I only have VS2008 Express C++ edition installed.  How much effort is
> likely required to get it working with 2010, or should I just work on
> getting it to use 2008?

The only thing that didn't work for me using VS2010 was a crash in
climaker.exe, everything else works perfectly fine. The LibO 3.3 I was
using in the old machine was compiled with VS2010 (using a
climaker.exe compiled with VS2008)

The stack trace of the crash was the one Tor mentioned previously. So
I guess it's just a matter of fixing this and we can announce support
for this compiler.

-- 
Jesús Corrius 
Document Foundation founding member
Skype: jcorrius | Twitter: @jcorrius
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Problems with windows build

[Steven Butler]

Hi Jesús

2011/2/5 Jesús Corrius :
> The stack trace of the crash was the one Tor mentioned previously. So
> I guess it's just a matter of fixing this and we can announce support
> for this compiler.

I ended up uninstalling VS2010 and it seems to have built now (but I
have other issues now).

Thanks for your help.

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

Re: [Libreoffice] Problems with windows build

[Michael Meeks]

Hi there,

On Fri, 2011-02-04 at 06:41 -0700, Tor Lillqvist wrote:
> > And after a while of dismissing these, saxparser goes into an infinite loop.
> 
> For me, saxparser crashes... I am debugging that but not really getting much
..
> iterator i is iterating so that i points to some bogus data and
> i->directBaseMemberOffset is a totally bogus and then the next
> round in the enclosing for loop on line 1226 the indexing crashes.

I wonder if the stlport iterators were simply more robust against
changes in the underlying structures. Is this a list it is iterating or
a hash ? If the latter then changes in the 'hash' had undefined (but
non-crashy) behaviour with stlport.

HTH,

Michael.

-- 
 michael.me...@novell.com  <><, Pseudo Engineer, itinerant idiot


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

Re: [Libreoffice] Problems with windows build

[Steven Butler]

Hi,

On 14 February 2011 21:05, Michael Meeks  wrote:

>        I wonder if the stlport iterators were simply more robust against
> changes in the underlying structures. Is this a list it is iterating or
> a hash ? If the latter then changes in the 'hash' had undefined (but
> non-crashy) behaviour with stlport.

I remember writing some code a number of years ago that iterated over
a map and deleted 'expired' items during iteration.

Using libstdc++ on CentOS 4 vintage I definitely had to take a local
copy of the iterator, move on to the next item using ++ii, then delete
the item using the copy of the iterator (and never use the copy
again), otherwise it would crash.

The code didn't look as pretty as using a simple for
(std::map::iterator ii(foo.begin(); ii!= foo.end(); ++ii)
loop, but at least it worked.

I think there is no guarantee in STL for certain data types (like
maps) when you erase the value at the iterator.  I never used the hash
- it always seemed to use more memory than maps, and wasn't any faster
with what I was trying to do.

STLport might be a bit more clever about this kind of (ab)use, or it
might just be luck.

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

Re: [Libreoffice] Problems with windows build

[Fridrich Strba]

Hello,

On Mon, 2011-02-14 at 11:05 +, Michael Meeks wrote:
> > For me, saxparser crashes... I am debugging that but not really getting much
>   I wonder if the stlport iterators were simply more robust against
> changes in the underlying structures. Is this a list it is iterating or
> a hash ? If the latter then changes in the 'hash' had undefined (but
> non-crashy) behaviour with stlport.

If it is the same crash we saw during FOSDEM, it is due to the fact that
with the hash_* containers of stlport, erasing the element pointed to by
the one-beyond-the-end iterator was graciously handled, whereas the
boost::unordered ones are crashing with it. But the fix is just easy by
checking whether the corresponding find did not return this kind of
iterator and perform the erase only then.

Cheers

Fridrich

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

Re: [Libreoffice] Problems with Windows build

[Tor Lillqvist]

> $ source *Env.Set.sh
> bash: *Env.Set.sh: No such file or directory

For some reason lost in history (or just a random choice made by somebody 
without much thinking), the corresponding file for Windows is called 
winenv.set.sh , in lowercase.

Yeah, we probably should rename it to WinEnv.Set.sh for consistency. 

Yes, the file system on Windows is case-insensitive, but Cygwin tries hard to 
be a kind of Unix (and mostly succeeds; it's the interaction between Cygwin and 
the surrounding non-Cygwin world that causes trouble), and the file name 
winenv.set.sh thus does not match the wildcard pattern *Env.Set.sh .

--tml


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

[Libreoffice] problems in number format dialog

[Markus Mohrhard]

Hello,

can someone from the Thai community check whether these two patches cause
any problems. They remove some part of the bug fix for
https://bugs.freedesktop.org/show_bug.cgi?id=33089 with patch
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=6b5a84d339676d6e34c17cbefbec427e4559f37awhich
broke several parts of the number format dialog. If there are no
objections I would like to push these patches in some days because it will
help to get the number format dialog to work again. At the moment we have
problems with colors in the number format code and strange switching between
different categories when you click on the "Show negative numbers red"
checkbox.

Regards,
Markus
From 10e028a9ea7e925f785558eca3fb4076fd689617 Mon Sep 17 00:00:00 2001
From: Katarina Machalkova 
Date: Thu, 28 Jul 2011 14:50:24 +0200
Subject: [PATCH 2/3] Don't delete valid [$.*] components of number formats

... such as [RED], [NatNumX] etc.
---
 svl/source/numbers/zformat.cxx |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx
index cfc9169..b567c20 100644
--- a/svl/source/numbers/zformat.cxx
+++ b/svl/source/numbers/zformat.cxx
@@ -636,6 +636,7 @@ SvNumberformat::SvNumberformat(String& rString,
 
 sal_Bool bCancel = sal_False;
 sal_Bool bCondition = sal_False;
+sal_Bool bHasValidBracketPrefix = sal_False;
 short eSymbolType;
 xub_StrLen nPos = 0;
 xub_StrLen nPosOld;
@@ -727,6 +728,8 @@ SvNumberformat::SvNumberformat(String& rString,
 bCancel = sal_True; // break for
 nCheckPos = nPosOld;
 }
+else
+bHasValidBracketPrefix = sal_True;
 }
 }
 break;
@@ -763,6 +766,7 @@ SvNumberformat::SvNumberformat(String& rString,
 sal_uInt8 nNum = sal::static_int_cast< sal_uInt8 >(0 - (eSymbolType - BRACKET_SYMBOLTYPE_NATNUM0));
 sStr += String::CreateFromInt32( nNum );
 NumFor[nIndex].SetNatNumNum( nNum, sal_False );
+bHasValidBracketPrefix = sal_True;
 }
 }
 break;
@@ -788,6 +792,7 @@ SvNumberformat::SvNumberformat(String& rString,
 sal_uInt8 nNum = sal::static_int_cast< sal_uInt8 >(1 - (eSymbolType - BRACKET_SYMBOLTYPE_DBNUM1));
 sStr += static_cast< sal_Unicode >('0' + nNum);
 NumFor[nIndex].SetNatNumNum( nNum, sal_True );
+bHasValidBracketPrefix = sal_True;
 }
 }
 break;
@@ -812,6 +817,7 @@ SvNumberformat::SvNumberformat(String& rString,
 sStr.AssignAscii( RTL_CONSTASCII_STRINGPARAM("$-") );
 sStr = sStr + maLocale.generateCode();
 NumFor[nIndex].SetNatNumLang(maLocale.meLanguage);
+bHasValidBracketPrefix = sal_True;
 }
 }
 }
@@ -820,7 +826,7 @@ SvNumberformat::SvNumberformat(String& rString,
 if ( !bCancel )
 {
 rString.Erase(nPosOld,nPos-nPosOld);
-if (maLocale.meLanguage != 0)
+if ( bHasValidBracketPrefix )
 {
 rString.Insert(sStr,nPosOld);
 nPos = nPosOld + sStr.Len();
-- 
1.7.3.4

From b597125fa5271c5c707a4945355035c1463c2ac4 Mon Sep 17 00:00:00 2001
From: Markus Mohrhard 
Date: Fri, 29 Jul 2011 00:42:35 +0200
Subject: [PATCH 3/3] revert part of 6b5a84d339676d6e34c17cbefbec427e4559f37a

the patch caused some problems in the number format dialog, we can't add
an additional condition without new fallback
---
 svl/source/numbers/zformat.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx
index b567c20..8a267d7 100644
--- a/svl/source/numbers/zformat.cxx
+++ b/svl/source/numbers/zformat.cxx
@@ -812,7 +812,7 @@ SvNumberformat::SvNumberformat(String& rString,
 bCancel = sal_True; // break for
 nCheckPos = nPosOld;
 }
-else if (maLocale.meLanguage != 0)
+else
 {
 sStr.AssignAscii( RTL_CONSTASCII_STRINGPARAM("$-") );
 sStr = sStr + maLocale.generateCode();
-- 
1.7.3.4

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
h

Re: [Libreoffice] problems in number format dialog

[Eike Rathke]

Hi Markus,

On Friday, 2011-07-29 00:54:19 +0200, Markus Mohrhard wrote:

> can someone from the Thai community check whether these two patches cause
> any problems. They remove some part of the bug fix for
> https://bugs.freedesktop.org/show_bug.cgi?id=33089 with patch
> http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=6b5a84d339676d6e34c17cbefbec427e4559f37awhich
> broke several parts of the number format dialog.

Not from the Thai community ;) but ... Good catch, though it occurs to
me that the patch cures only a symptom. First, initialization of
bHasValidBracketPrefix should be inside the

else if ( lcl_SvNumberformat_IsBracketedPrefix( eSymbolType) ) 

block, like so

else if ( lcl_SvNumberformat_IsBracketedPrefix( eSymbolType ) )
{
bool bHasValidBracketPrefix = false;

because bracketed prefixes are evaluated for each of the possible 4 sub
formats and one sub format can have more than one prefix. With this the
actual value of bHasValidBracketPrefix at the end of the switch always
equals !bCancel, the prerequisite to execute the final block, so the old
code is always executed and the new code

else
{
nPos = nPosOld; // Excel LCID removed
}

of the malicious change never is. If I didn't overlook some path at some
place..

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpJxxbQvkqLs.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] problems in number format dialog

[Eike Rathke]

Hi Markus,

On Friday, 2011-07-29 23:00:45 +0200, Eike Rathke wrote:

> Not from the Thai community ;) but ... Good catch, though it occurs to
> me that the patch cures only a symptom.

I took a stab at this, the "Excel LCID removed" part may indeed be
superfluous, need to step through some more cases to verify/deny.
Anyway, already the code in SvNumberformat::ImpNextSymbol() fiddling
around with the input string for Thai calendar/digits at that place is
totally broken. I'll come up with some solution.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpegJCSI8XsB.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] problems in number format dialog

[Samphan Raruenrom]

On Fri, Jul 29, 2011 at 5:54 AM, Markus Mohrhard <
markus.mohrh...@googlemail.com> wrote:

>
> can someone from the Thai community check whether these two patches cause
> any problems.
>

We're reading this discussion and patches.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] problems in number format dialog

[Eike Rathke]

Hi Samphan,

On Monday, 2011-08-01 11:54:31 +0700, Samphan Raruenrom wrote:

> We're reading this discussion and patches.

Great, could you please apply the attached patches and check if that
suits the needs of the Thai community?

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD
fdo#38956 related changes in split components repository to support LCID changes

From: Eike Rathke 


---
 cui/source/tabpages/numfmt.cxx |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/cui/source/tabpages/numfmt.cxx b/cui/source/tabpages/numfmt.cxx
index 03fb706..b92831e 100644
--- a/cui/source/tabpages/numfmt.cxx
+++ b/cui/source/tabpages/numfmt.cxx
@@ -1394,6 +1394,10 @@ IMPL_LINK( SvxNumberFormatTabPage, ClickHdl_Impl, 
ImageButton*, pIB)
 
 if ( !nErrPos ) // Syntax ok?
 {
+// May be sorted under a different locale if LCID was parsed.
+if (bAdded)
+aLbLanguage.SelectLanguage( pNumFmtShell->GetCurLanguage() );
+
 if(nCatLbSelPos==CAT_CURRENCY)
 {
 
aLbCurrency.SelectEntryPos((sal_uInt16)pNumFmtShell->GetCurrencySymbol());
fdo#38956 related changes in split libs-core repository to support LCID changes

From: Eike Rathke 


---
 svx/source/items/numfmtsh.cxx |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/svx/source/items/numfmtsh.cxx b/svx/source/items/numfmtsh.cxx
index 837fdea..9f70817 100644
--- a/svx/source/items/numfmtsh.cxx
+++ b/svx/source/items/numfmtsh.cxx
@@ -289,6 +289,20 @@ sal_Bool SvxNumberFormatShell::AddFormat( String& rFormat, 
 xub_StrLen& rErrPos,
 bInserted = pFormatter->PutEntry( rFormat, rErrPos,
   nCurCategory, nAddKey,
   eCurLanguage );
+if (bInserted)
+{
+// May be sorted under a different locale if LCID was parsed.
+const SvNumberformat* pEntry = pFormatter->GetEntry( nAddKey);
+if (pEntry)
+{
+LanguageType nLang = pEntry->GetLanguage();
+if (eCurLanguage != nLang)
+{
+// Current language's list would not show entry, adapt.
+eCurLanguage = nLang;
+}
+}
+}
 }
 
 if ( bInserted ) // eingefuegt
Fix fdo#38956 discarding bracketed prefixes in number formats, such as [RED]

From: Eike Rathke 

* Fixed discarding of prefixes.
* Fixed the broken handling of Thai calendar and numerals speciality.
* Added bits to actually display a format with embedded LCID in the dialog.
---
 svl/inc/svl/zforlist.hxx|   16 
 svl/source/numbers/zforlist.cxx |2 +
 svl/source/numbers/zformat.cxx  |  139 ++-
 3 files changed, 125 insertions(+), 32 deletions(-)

diff --git a/svl/inc/svl/zforlist.hxx b/svl/inc/svl/zforlist.hxx
index eef1904..d1519ea 100644
--- a/svl/inc/svl/zforlist.hxx
+++ b/svl/inc/svl/zforlist.hxx
@@ -42,6 +42,7 @@
 #include 
 
 #include 
+#include 
 
 class Date;
 class SvStream;
@@ -225,6 +226,8 @@ typedef Table SvNumberFormatterIndexTable;
 
 typedef ::std::map< sal_uInt32, sal_uInt32 > SvNumberFormatterMergeMap;
 
+typedef ::std::set< LanguageType > NfInstalledLocales;
+
 
 /** Language/country dependent currency entries
  */
@@ -343,6 +346,9 @@ public:
  */
 static const sal_uInt16 INPUTSTRING_PRECISION;
 
+/** THE set of installed locales. */
+static NfInstalledLocales theInstalledLocales;
+
 /// Preferred ctor with service manager and language/country enum
 SvNumberFormatter(
 const ::com::sun::star::uno::Reference< 
::com::sun::star::lang::XMultiServiceFactory >& xSMgr,
@@ -801,6 +807,16 @@ public:
 /// Skip a NumberFormatter in stream, Chart needs this
 static void SkipNumberFormatterInStream( SvStream& );
 
+/** Check if a specific locale has supported locale data. */
+static bool IsLocaleInstalled( LanguageType eLang )
+{
+// The set is initialized as a side effect of the currency table 
+// created, make sure that exists, which usually is the case unless a 
+// SvNumberFormatter was never instanciated.
+GetTheCurrencyTable();
+return theInstalledLocales.find( eLang) != theInstalledLocales.end();
+}
+
 
 private:
 ::com::sun::star::uno::Reference< 
::com::sun::star::lang::XMultiServiceFactory > xServiceManager;
diff --git a/svl/source/numbers/zforlist.cxx b/svl/source/numbers/zforlist.cxx
index bc0df6a..a4a0c82 100644
--- a/svl/source/numbers/zforlist.cxx
+++ b/svl/source/numbers/zforlist.cxx
@@ -195,6 +195,7 @@ SV_IMPL_PTRARR( NfWSStringsDtor, String* );
 
 const sal_uInt16 SvNumberFormatter::UNLIMITED_PRECISION   = 
::std::numeric_limits::max();
 const sal_uInt16 SvNumberFormatter::INPUTSTRING_PR

Re: [Libreoffice] problems in number format dialog

[Eike Rathke]

Hi Samphan,

On Monday, 2011-08-01 18:29:49 +0200, Eike Rathke wrote:

> On Monday, 2011-08-01 11:54:31 +0700, Samphan Raruenrom wrote:
> > We're reading this discussion and patches.
> Great, could you please apply the attached patches and check if that
> suits the needs of the Thai community?

As I didn't see any veto I pushed the fix to master, with some slight
modifications.

http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=fbe916fd7dc7ba22b8652bc0c5b8a0d9cb15cc9d
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?id=513e2e78a9bb0861064f73c17000afd75239c7a6
http://cgit.freedesktop.org/libreoffice/components/commit/?id=6e260f61494a21e45513d339688e05c9799a6aa6

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpp5bF1MUea6.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Problems with mozilla build-tools on WindowsXP

[Rob Snelders]

Hi All,

I have followed [1] as a guide to build LO on windows. But when I run 
autogen it comes with "Mozilla build tooling incomplete".


I run autogen with the options 
--with-mozilla-build='/cygwin/c/mozilla-build and --disable-build-mozilla.


I have also downloaded the prebuild mozilla modules and set them in 
moz/zipped


When it failed I downloaded the moztools-static.zip from the 
mozilla-buildtools-ftp and put that in the buildtools-directory. But 
that also didn't help.


Does anybody knows why this error is given?

[1] 
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies


--
Greetings,
Rob Snelders
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] problems with encryption if thunderbird is installed

[Markus Mohrhard]

Hey,

I have been debugging the problem Laurent mentioned lately that
opening a password encrypted library causes Libreoffice to need a lot
of cpu time even after loading finished.

During my investigation I now found two some interesting points:
- the bug does not happen if you don't have thunderbird installed
(maybe it is also necessary to have a profile)
- the problem is in
connectivity/source/drivers/mozab/bootstrap/MNSInit.cxx:228-235
-- the loop is sleeping for 1 ms and therefore running a thousand
times per second without doing any real work because there are no
events

Since this also affects Loading of encrypted documents do we really
need to initialize mozilla there? It should work now also without
mozilla or am I missing something( see nssinitializer.cxx:197 ). If it
is still needed, can't we stop the Mozilla_UI_Thread after we opened
the encrypted document/library?
Another easy solution to improve the situation might be to increase
the timeout in MNSInit.cxx:235 from 1 to 10 or even 100, but I think
that is more a workaround than fixing the underlying problem.

Do we have someone who knows this code well enough to fix that for
3-5-0 or should we "fix" it there with the above mentioned workaround?

I think a solution would be really necessary since this loop needs
around 40% of one core on my fast development computer and Laurent
mentioned around 40% of his whole cpu time( so I suspect 80% of one
core for him )

I hope for some good ideas ;)

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Makoto Takizawa]

hi
I just success build on windows and wrote a note on wiki.
https://wiki.documentfoundation.org/User:Foral/Build_Win

around Mozilla, needed to download a lot of stuffs.

(2011/11/24 8:10), Rob Snelders wrote:

Hi All,

I have followed [1] as a guide to build LO on windows. But when I run
autogen it comes with "Mozilla build tooling incomplete".

I run autogen with the options
--with-mozilla-build='/cygwin/c/mozilla-build and --disable-build-mozilla.

I have also downloaded the prebuild mozilla modules and set them in
moz/zipped

When it failed I downloaded the moztools-static.zip from the
mozilla-buildtools-ftp and put that in the buildtools-directory. But
that also didn't help.

Does anybody knows why this error is given?

[1]
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies




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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Caolán McNamara]

On Thu, 2011-11-24 at 00:10 +0100, Rob Snelders wrote:
> When it failed I downloaded the moztools-static.zip from the 
> mozilla-buildtools-ftp and put that in the buildtools-directory. But 
> that also didn't help.
> 
> Does anybody knows why this error is given?

We need to build "nss", and nss requires the mozilla build tooling under
windows, regardless of whether mozilla itself is built it not. nss is
used by a few things directly by LibreOffice, not just as a build-req
for the mozilla stuff.

Easiest to install the mozilla tools installer from 
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32 and run
it, it will install into something like c:\mozilla-tools

and configure with --with-mozilla-build=/c/mozilla-tools (or whereever
it does)

C.

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Fridrich Strba]

On 24/11/11 10:14, Caolán McNamara wrote:
> and configure with --with-mozilla-build=/c/mozilla-tools (or whereever
> it does)

I would use --with-mozilla-build=c:/mozilla-tools which is a path that
cygwin understands and the native Windows too.

Cheers

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Regina Henschel]

Hi,

Makoto Takizawa schrieb:

hi
I just success build on windows and wrote a note on wiki.
https://wiki.documentfoundation.org/User:Foral/Build_Win

around Mozilla, needed to download a lot of stuffs.


Perhaps you consolidate your things, which are not yet mentioned, 
directly into

https://wiki.documentfoundation.org/Development/BuildingOnWindowsWithCygwinAndMSVCExpress
and
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Mat M]

Hi Makoto

Le Thu, 24 Nov 2011 02:46:53 +0100, Makoto Takizawa  
 a écrit:



hi
I just success build on windows and wrote a note on wiki.
https://wiki.documentfoundation.org/User:Foral/Build_Win
 Glad you succeed ! I ma still a bit surprised by the fact you had no  
issue with (x86) in your paths with default autogen.sh & configure.in.


I tried from master and need to tweak variables in Env.host.sh to go  
further. could you confirm you had no prob with that ?


Thanks Mathias



around Mozilla, needed to download a lot of stuffs.

(2011/11/24 8:10), Rob Snelders wrote:

Hi All,

I have followed [1] as a guide to build LO on windows. But when I run
autogen it comes with "Mozilla build tooling incomplete".

I run autogen with the options
--with-mozilla-build='/cygwin/c/mozilla-build and  
--disable-build-mozilla.


I have also downloaded the prebuild mozilla modules and set them in
moz/zipped

When it failed I downloaded the moztools-static.zip from the
mozilla-buildtools-ftp and put that in the buildtools-directory. But
that also didn't help.

Does anybody knows why this error is given?

[1]
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies


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

Re: [Libreoffice] problems with encryption if thunderbird is installed

[Laurent Godard]

Hi Markus

Thanks a lot of taking care !
I also identified the source code you pointed, but my skills stucked me

> I think a solution would be really necessary since this loop needs
> around 40% of one core on my fast development computer and Laurent
> mentioned around 40% of his whole cpu time( so I suspect 80% of one
> core for him )

i experience the same as you : 40% of one core

thanks again

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

Re: [Libreoffice] problems with encryption if thunderbird is installed

[Stephan Bergmann]

On 01/27/2012 12:11 AM, Markus Mohrhard wrote:

- the problem is in
connectivity/source/drivers/mozab/bootstrap/MNSInit.cxx:228-235
-- the loop is sleeping for 1 ms and therefore running a thousand
times per second without doing any real work because there are no
events

Since this also affects Loading of encrypted documents do we really
need to initialize mozilla there? It should work now also without
mozilla or am I missing something( see nssinitializer.cxx:197 ).


No idea.


If it is still needed, can't we stop the Mozilla_UI_Thread after we
opened the encrypted document/library?


There's already code there to stop the thread (halleluja), but 
apparently only upon LO shutdown 
(connectivity/source/drivers/mozab/mozillasrc/MNSTerminateListener.cxx). 
 Hard to tell for me whether there's some easy and safe way to stop it 
earlier (with the added requirement that it can also be restarted 
correctly later, in case another document is loaded later, and that 
start/stop is race-free in the face of multiple documents being loaded 
simultaneously).


Generally, I would not go near that code (an osl::Condition with 
multiple set/reset is already enough to make me scream, and a missing 
osl_joinWithThread does not raise my confidence, either).



Another easy solution to improve the situation might be to increase
the timeout in MNSInit.cxx:235 from 1 to 10 or even 100, but I think
that is more a workaround than fixing the underlying problem.


Sounds like the best fix to me, at least for -3-5-0.

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

Re: [Libreoffice] Problems with mozilla build-tools on WindowsXP

[Makoto Takizawa]

Hi Mat.

sorry for late reply.

I was able to build with that option but
Unfortunately I can not build on windows at the moment.
I got error in someplace and have not solved until now.
I will update that wiki when I can solve.

ps
Windows build is too slow so usually I build on Linux.


(24/01/2012 6:58 a.m.), Mat M wrote:
> Hi Makoto
> 
> Le Thu, 24 Nov 2011 02:46:53 +0100, Makoto Takizawa
>  a écrit:
> 
>> hi
>> I just success build on windows and wrote a note on wiki.
>> https://wiki.documentfoundation.org/User:Foral/Build_Win
>  Glad you succeed ! I ma still a bit surprised by the fact you had no
> issue with (x86) in your paths with default autogen.sh & configure.in.
> 
> I tried from master and need to tweak variables in Env.host.sh to go
> further. could you confirm you had no prob with that ?
> 
> Thanks Mathias
> 
>>
>> around Mozilla, needed to download a lot of stuffs.
>>
>> (2011/11/24 8:10), Rob Snelders wrote:
>>> Hi All,
>>>
>>> I have followed [1] as a guide to build LO on windows. But when I run
>>> autogen it comes with "Mozilla build tooling incomplete".
>>>
>>> I run autogen with the options
>>> --with-mozilla-build='/cygwin/c/mozilla-build and
>>> --disable-build-mozilla.
>>>
>>> I have also downloaded the prebuild mozilla modules and set them in
>>> moz/zipped
>>>
>>> When it failed I downloaded the moztools-static.zip from the
>>> mozilla-buildtools-ftp and put that in the buildtools-directory. But
>>> that also didn't help.
>>>
>>> Does anybody knows why this error is given?
>>>
>>> [1]
>>> http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies
>>>
>>>
> 

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

[Libreoffice] Problems presentation to an external display or projector

[Yusniel E. Alfonso]

I am a ubuntu user, please excuse my English is not very good. Do not
know if it's a bug or maybe a setting that I do and I did not. It
turns out I use my laptop and other LCD monitor when I open an Impress
presentation and I want to put it in presentation mode, because as
usual to OpenOffice, I drew a presentation to the external display and
pressing F5 when in presentation mode was coming down in Libreoffice
Something similar happens to me except that I get the display on the
monitor of the portail and I want to leave the external monitor or
projector to be connected.
thank you very much.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Problems Using existing User Profile after upgrade to 3.5

[Rainer Bielefeld]

Hi,

currently I have much trouble using existing user profiles with Master 
or 3.5.0 Beta. The trouble vanishes when I switch to a blank new user 
profile for.


I believe that might cause heavy trouble when users update from 3.4 8or 
3.3), but on the other hand my suspect might be complete nonsense 
because a correct 3.5 installation will adapt User Profile to avoie trouble?


Please help to collect all Bugs that might be related to existing User 
Profile in
"[Bug 43489] New: [Task] Incorrect behavior using existing User Profile 
for upgrade"


to prove or falsify that suspect.

Discussion in , please!

Kind regards

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

Re: [Libreoffice] Problems presentation to an external display or projector

[Thorsten Behrens]

Yusniel E. Alfonso wrote:
> I am a ubuntu user, please excuse my English is not very good. Do not
> know if it's a bug or maybe a setting that I do and I did not.
>
This is a developer list - please refer to
http://wiki.documentfoundation.org/Development/Use_of_MailList for
what's on-topic here. Bugs should go to bugs.freedesktop.org.

Thanks,

-- Thorsten


pgpTnKfINhI7D.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice