Re: [dev] OpenOffice XComponent, XComponentContext and thread safety....
On 09/08/08 21:09, ashok _ wrote: I have a java swing application that works as a UNO Client by loading and connecting to OpenOffice.org Writer... The openoffice XComponent handle is accessed by the main thread of the application, and also by other parts of the program whcih update the UI and run as SwingWorker threads... I am having random crashes with the following exception being raised : java.io.EOFException at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge$MessageDispatcher.run(java_remote_bridge.java:176) Does this happen because the OOo XComponent handle is accessed across thread boundaries ? Most probably that Java exception is caused by the soffice process crashing, so you would need to have an eye on the soffice process (e.g., attach with a debugger; OOo's crash handling might prevent a core being generated for a process that would otherwise generate one). And yes, multithreaded access to OOo is known to be, erm, adventurous. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OpenOffice XComponent, XComponentContext and thread safety....
On Tue, Sep 9, 2008 at 9:54 AM, Stephan Bergmann [EMAIL PROTECTED] wrote: Most probably that Java exception is caused by the soffice process crashing, so you would need to have an eye on the soffice process (e.g., attach with a debugger; OOo's crash handling might prevent a core being generated for a process that would otherwise generate one). And yes, multithreaded access to OOo is known to be, erm, adventurous. Thanks for the feedback... Does that mean if i have a java Swing UNO client, the only way to safely access the XComponent handler is to run all the document processing via the XComponent handle on the main event dispatch thread (EDT ? ) rather than a background thread... ? Is there a better way to do thisbecause running all the document processing on the EDT slows everything down... ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OpenOffice XComponent, XComponentContext and thread safety....
On 09/09/08 09:47, ashok _ wrote: On Tue, Sep 9, 2008 at 9:54 AM, Stephan Bergmann [EMAIL PROTECTED] wrote: Most probably that Java exception is caused by the soffice process crashing, so you would need to have an eye on the soffice process (e.g., attach with a debugger; OOo's crash handling might prevent a core being generated for a process that would otherwise generate one). And yes, multithreaded access to OOo is known to be, erm, adventurous. Thanks for the feedback... Does that mean if i have a java Swing UNO client, the only way to safely access the XComponent handler is to run all the document processing via the XComponent handle on the main event dispatch thread (EDT ? ) rather than a background thread... ? Is there a better way to do thisbecause running all the document processing on the EDT slows everything down... ? You could move all communication with OOo to a single thread (which need not necessarily be the EDT, but could also be a dedicated thread you create), or use mutexes to avoid multiple threads communicating with OOo simultaneously. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Howto get the actual interface type of an UNO service object (via Java) ?
Hi there, while poking around a little bit I was wondering, how one could get at the Type[...] information via Java that the Java proxy object reveals, if asking it to render to a string. E.g. in the following (interactive) session Java is used as the bridge for the scripting language ooRexx; first a Desktop service object is created and assigned to a variable a, then its com.sun.star.frame.XDesktop interface is assigned to variabel b and from it the com.sun.star.beans.XPropertySet interface is assigned to variable c. Sending the toString message to all three proxy objects displays them allowing to distinguish which interface type they represent. In the example session below (please watch out for line-wraps) that interface type is the last comma separated token in the form of Type[...interface_name...]. Now the question: how can one get at exactly that piece of information via Java at runtime? E:\rony\dev\bsf\src\binrexxtry REXX-ooRexx_3.2.0(MT) 6.02 16 Jun 2008 rexxtry.rex lets you interactively try REXX statements. Each string is executed when you hit Enter. Enter 'call tell' for a description of the features. Go on - try a few...Enter 'exit' to end. call uno.cls ... rexxtry.rex on WindowsNT a=uno.createDesktop() /* creates and returns a desktop service object */ ... rexxtry.rex on WindowsNT b=a~XDesktop /* queries the com.sun.star.frame.XDestkop interface */ ... rexxtry.rex on WindowsNT c=b~XPropertySet /* queries the com.sun.star.beans.XPropertySet interface */ ... rexxtry.rex on WindowsNT say a~toString /* ask the proxy for its string representation */ [Proxy:9938272,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.uno.XInterface]] ... rexxtry.rex on WindowsNT say b~toString /* ask the proxy for its string representation */ [Proxy:32134769,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.frame.XDesktop]] ... rexxtry.rex on WindowsNT say c~toString /* ask the proxy for its string representation */ [Proxy:30495813,4c801ac;msci[0];71a4c62fd6a4ea18dca702d3c4a726d,Type[com.sun.star.beans.XPropertySet]] ... rexxtry.rex on WindowsNT say a~uno.getTypeName b~uno.getTypeName c~uno.getTypeName /* get the IDL type name via reflection */ UNO_SERVICE UNO_SERVICE UNO_SERVICE ... rexxtry.rex on WindowsNT say uno.areSame(a,b) uno.areSame(b,c) uno.areSame(a,c) /* test whether all three are the same object */ 1 1 1 ... rexxtry.rex on WindowsNT TIA for any pointers/hints, ---rony
Re: [dev] OOo 3 antialias ldraw
Nguyen Vu Hung a écrit : Hi all, Please take a look at the attached .odt file. In the first slide: 1. All lines( which are Impress drawing objects) are not(?) antialiased and we can see the zig-zags. 2. The .pdf file exported from this .odt looks smooth. In the second slide, I've imported a png file to it( antialias.test.png) 1. Lines looks smooth in Impress 2. However, lines the exported pdf are not smooth. Please view the .odt file with 100% zoom, view .pdf file with Acrobat reader 5.0 100% zoom or Foxit Reader 2.2. My environment: Windows XP SP3, Japanese. OOO300m5, Buld 9350. Should I commit an issue? Perhaps it 's not necessary : http://www.openoffice.org/issues/show_bug.cgi?id=28526 Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo 3 antialias ldraw
2008/9/10 Jean-Baptiste Faure [EMAIL PROTECTED] Nguyen Vu Hung a écrit : In the second slide, I've imported a png file to it( antialias.test.png) 1. Lines looks smooth in Impress 2. However, lines the exported pdf are not smooth. Please view the .odt file with 100% zoom, view .pdf file with Acrobat reader 5.0 100% zoom or Foxit Reader 2.2. Perhaps it 's not necessary : http://www.openoffice.org/issues/show_bug.cgi?id=28526 28526 refers to anti-aliasing for drawing objects, which I've mentioned in the first slide. In the second slide, the bug is that when we export an imported bitmap to a pdf, there is no anti-aliasing. Please take a look at 2nd page in the .pdf file I've send in my first email. -- Best Regards, Nguyen Hung Vu ( Nguyễn Vũ Hưng ) [EMAIL PROTECTED] [EMAIL PROTECTED], YIM: vuhung16 , Skype: vuhung16dg Life through a viewfinder: http://bighugelabs.com/flickr/[EMAIL PROTECTED]
