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 envi
> > 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
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
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 UnoUrlResolver
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
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 brok
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 - unfortunate
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 ab
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 brok
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 experiment
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 no
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 b
On 02/22/2012 12:56 PM, Michael Meeks wrote:
So - the question would be then, how much of UNO is usable via the
in-line C wrappers ? I was under the impression that lots of it should
be - but perhaps I'm in cloud cuckoo land ;-)
With "in-line C wrappers" you mean the inline C++ code in
On 02/22/2012 11:53 AM, Helmar Spangenberg wrote:
My understanding of the whole subject still is too small - I thought,
once I got the context bootstrapped, the whole communication to the
office is done by a socket or a pipe.
Yes, but what gets communicated over that pipe is remote procedure
c
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
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 on
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
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 (eith
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).
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
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 de
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(), cppu::
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
> > lin
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 coming
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.
> 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.
-
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
> 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*
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
29 matches
Mail list logo
