On 06/30/2011 02:20 PM, vikt...@gmail.com wrote:
On 06/30/2011 10:27 AM, Tor Lillqvist wrote:
For example, is it possible to build just the module that is causing a
problem with the debug flags set, and replace just
that .dll in LibreOffice, rather than building the whole source?
SmoketestCommandEnvironment.java:34: package com.sun.star.ucb does not
exist
import com.sun.star.ucb.XCommandEnvironment;
I have build ucb - but I seem to have missed a module.
Anyone know which module provides this package?
Ah, found it in unoil!
On 06/29/2011 07:47 PM, Vik Tara wrote:
On Wed, Jun 29, 2011 at 6:15 PM, Tor Lillqvist tlillqv...@novell.com
mailto:tlillqv...@novell.com wrote:
Can I actually build the windows binaries on linux?
Not yet.
OK - reviewed the windows build instructions - doesn't look like much
For example, is it possible to build just the module that is causing a
problem with the debug flags set, and replace just
that .dll in LibreOffice, rather than building the whole source?
You also need to build the modules that it depends on. Depending on how high in
the dependency hierarchy
One of the problems I am facing is there is a hang from my app
communcatiing with Libre. Again it always seems to be at the stage of
getting the list of text fields:
xTextFieldsSupplier.getTextFields();
This results in the system hanging and upon inspection of the stack
trace it appears to be
On 06/30/2011 10:27 AM, Tor Lillqvist wrote:
For example, is it possible to build just the module that is causing a
problem with the debug flags set, and replace just
that .dll in LibreOffice, rather than building the whole source?
You also need to build the modules that it depends on.
Thank you for your help on this. I am building the debug now, not sure
if this helps in any way but it appears that nearly all points of
failure start with this line:
XTextFieldsSupplier xTextFieldsSupplier =
(XTextFieldsSupplier)UnoRuntime.queryInterface(XTextFieldsSupplier.class,
On Tue, Jun 28, 2011 at 3:55 PM, Stuart Ledwich (Hotmail)
stuart_ledw...@hotmail.com wrote:
Either problem seems to happen on either the IDocument.getTextFields or
IDocument.close.
Either textDocument object is null or the XTextDocument returned by
getXTextDocument() is null maybe ?
Try
Hi,
This is windows, so not my primary platform, but IIRC attach to
process in one of the MSVisual Studio menus will do the right thing,
just looks for soffice in the list.
I am also working on this problem.
This is what I get when attaching to the process:
The thread 'Win32 Thread'
Hi,
If it is crashing on the server side you may have to build your own
LibreOffice from source and rebuild the lib in which it crashes with
debugging symbols, e.g.
http://wiki.documentfoundation.org/Development/Native_Build#Partial_debug_build
to get something more useful out of it.
Can I actually build the windows binaries on linux?
Not yet.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On Wed, Jun 29, 2011 at 6:15 PM, Tor Lillqvist tlillqv...@novell.comwrote:
Can I actually build the windows binaries on linux?
Not yet.
OK - reviewed the windows build instructions - doesn't look like much fun -
but will try it ;)
Is there an easier way than building everything for me to
I am currently using openoffice 3.3 on windows (tested on Windows XP sp3
and Windows7) and have a problem (linux is working well). I use NOA
(Nice Office Access) as a layer to uno - which appears to be working ok.
I connect to open office and all seems well, do some simple field
manipulation and
I just need to make it clear - I have refered to openoffice but I am
using LibreOffice, also tested with open office and got the same
results.
Thanks
On Tue, 2011-06-28 at 13:55 +0100, Stuart Ledwich (Hotmail) wrote:
I am currently using openoffice 3.3 on windows (tested on Windows XP sp3
and
14 matches
Mail list logo
