Hello all,
finally I could solve the problem. Basically, for the Windows installation, I
had to adjust uno.ini in the working directory of my remote control
according to my installation of LO. Furthermore, there are some weird
inconsistencies concerning URLs. Under Windows I had to set 2
Hi Helmar,
On Thu, 2012-03-08 at 17:25 +0100, Helmar Spangenberg wrote:
finally I could solve the problem.
Great news ! :-)
UNO_PATH=L:\blabla\libreoffice3.5\program
URE_MORE_TYPES=file:///L:/blabla/libreoffice3.5/program/types/offapi.rdb
Now I even can use the MinGW-UNO with an
In case someone is interested I will supply a short example (Qt/MinGW
based) how to start an LO with an empty sheet of paper out of a small
program. I don't want to pollute the list, therefore tell me a
(central) address where to send the files to.
Sounds really useful - we should
Am Donnerstag, 23. Februar 2012, 12:49:13 schrieb Michael Stahl:
(...)
earlier this week i bootstrapped a little python thingy on Linux with
these variables (found by trial and error, not by actual understanding),
perhaps URE_BOOTSTRAP could be of interest to you:
I tried it - unfortunately
Am Donnerstag, 23. Februar 2012, 11:24:00 schrieb Michael Meeks:
On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
In the meantime I am a step further - having found some very annoying
things: The recent MinGW cross tool chain supplied for SuSE 12.1
(64bit) seems to be broken -
On Mon, 2012-02-27 at 13:07 +0100, Helmar Spangenberg wrote:
Checking a little further, it seems that the file uno.ini in my actual
working directory is analyzed to set up te local context (unfortunately I do
not understand the entries in that file - any hint?)
:-) So there are two
On 02/27/2012 01:07 PM, Helmar Spangenberg wrote:
Anyway - using the older toolchain I got a working testing environment and
proceded a little bit. I have the impression that the difficulties rise
building the local context. As far as I could debug it, everything looks fine
until a
Am Mittwoch, 22. Februar 2012, 11:56:13 schrieb Michael Meeks:
On Wed, 2012-02-22 at 11:39 +0100, Stephan Bergmann wrote:
I doubt that Helmar's application only uses C-based sal API after
initial setup. In which case that wrapper would buy you nothing.
So - the question would be
On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
In the meantime I am a step further - having found some very annoying things:
The recent MinGW cross tool chain supplied for SuSE 12.1 (64bit) seems to be
broken - at least with regards to the LibreOffice code.
Are you not
On 23/02/12 11:07, Helmar Spangenberg wrote:
What came to my mind: Since I moved the LibreOffice directories, could it be
possible that I have to adjust one or more ini-files? Furthermore, which
environment variables are used setting up the local context? Until now I did
some experiments
Am Donnerstag, 23. Februar 2012, 11:24:00 schrieb Michael Meeks:
On Thu, 2012-02-23 at 11:07 +0100, Helmar Spangenberg wrote:
In the meantime I am a step further - having found some very annoying
things: The recent MinGW cross tool chain supplied for SuSE 12.1
(64bit) seems to be broken -
Am Donnerstag, 23. Februar 2012, 14:48:14 schrieb Helmar Spangenberg:
Are you not using Fridrich's toolchain / bits from here:
https://build.opensuse.org/project/show?project=windows%3Amingw%3Awin32
All the best,
Michael.
Ah - I did not know about that URL
On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
The problem here appears not be C-based sal but C++-based cppuhelper
(using ::cppu::bootstrap()), which will only work if cppuhelper and
client code are compiled with the same compiler (either both MSVC or
both GCC).
I
On 02/22/2012 11:30 AM, Michael Meeks wrote:
On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
The problem here appears not be C-based sal but C++-based cppuhelper
(using ::cppu::bootstrap()), which will only work if cppuhelper and
client code are compiled with the same compiler
Am Mittwoch, 22. Februar 2012, 10:30:26 schrieb Michael Meeks:
On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
The problem here appears not be C-based sal but C++-based cppuhelper
(using ::cppu::bootstrap()), which will only work if cppuhelper and
client code are compiled with
Am Mittwoch, 22. Februar 2012, 11:39:14 schrieb Stephan Bergmann:
On 02/22/2012 11:30 AM, Michael Meeks wrote:
On Tue, 2012-02-21 at 17:51 +0100, Stephan Bergmann wrote:
The problem here appears not be C-based sal but C++-based cppuhelper
(using ::cppu::bootstrap()), which will only work if
On Wed, 2012-02-22 at 11:39 +0100, Stephan Bergmann wrote:
I doubt that Helmar's application only uses C-based sal API after
initial setup. In which case that wrapper would buy you nothing.
So - the question would be then, how much of UNO is usable via the
in-line C wrappers ? I was
Hello List,
I have a working Qt/C++ application connecting to the office using
::cppu::bootstrap().
After porting this application to MinGW, I got a BootstrapException saying
unexpected UNO exception caught: component context fails to supply service
com.sun.star.bridge.UnoUrlResolver of type
I'm using the MinGW-LibreOffice from the daily-build-service (2012-02-20);
the MinGW itself is the cross tool chain from SuSE 12.1.
I *think* it would be better to just use a normal stable (MSVC-built)
LibreOffice version, not the experimental MinGW build. I hope it
doesn't matter that *your*
Am Dienstag, 21. Februar 2012, 12:29:58 schrieb Tor Lillqvist:
I'm using the MinGW-LibreOffice from the daily-build-service
(2012-02-20); the MinGW itself is the cross tool chain from SuSE 12.1.
I *think* it would be better to just use a normal stable (MSVC-built)
LibreOffice version, not
I would love to use the MSVC version - however my application is based on
some essential MinGW parts, and until now I have not found a way to link my
application against the MSVC-DLLs coming with the LibreOffice SDK.
Hmm, ah, yes silly me, the joys of mixing compilers when using C++ APIs.
Hi Helmar,
On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:
I would love to use the MSVC version - however my application is based
on some essential MinGW parts, and until now I have not found a way to
link my application against the MSVC-DLLs coming with the LibreOffice
SDK.
On 02/21/2012 04:15 PM, Michael Meeks wrote:
On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:
I would love to use the MSVC version - however my application is based
on some essential MinGW parts, and until now I have not found a way to
link my application against the MSVC-DLLs
Am Dienstag, 21. Februar 2012, 15:15:56 schrieb Michael Meeks:
Hi Helmar,
On Tue, 2012-02-21 at 11:53 +0100, Helmar Spangenberg wrote:
I would love to use the MSVC version - however my application is based
on some essential MinGW parts, and until now I have not found a way to
link my
On 02/21/2012 06:31 PM, Helmar Spangenberg wrote:
actually the SAL C API seems to work nicely - after Tor's remarks I
re-installed the MSVC-SDK and tried to link my MinGW-code against ist.
However, the CPPU interface denies the linking - I observe undefined
references to cppu::bootstrap(),
Am Dienstag, 21. Februar 2012, 19:37:14 schrieb Stephan Bergmann:
On 02/21/2012 06:31 PM, Helmar Spangenberg wrote:
actually the SAL C API seems to work nicely - after Tor's remarks I
re-installed the MSVC-SDK and tried to link my MinGW-code against ist.
However, the CPPU interface denies
On 02/21/2012 09:05 PM, Helmar Spangenberg wrote:
Yes exactly, that is my problem. That's why I am bound to the MinGW port
of LibreOffice, but somehow the URE part has some problems.
Yeah, sorry, but I fear I have no idea for you there. UnoUrlResolver is
probably the first service that shall
27 matches
Mail list logo
