Re: [api-dev] IDL for the TextDocument service
Christian Junker wrote: A text document does support the XMultiServiceFactory indirectly. Directly the XMultiServiceFactory interface is supported by the DrawingDocumentFactory which is a service that every document - that contains a drawing page - has. This includes the text document. About the other interface I don't know. Sorry ... but the generic IDL for every document is css.document.OfficeDocument. The IDL css.drawing.DrawingDocumentFactory is deprecated and replaced by the IDL css.drawing.GenericDrawingDocument. Further this GenericDrawingDocument is the base of our draw/impress documents only and not the base of our writer/web/global nor of the calc or formula documents. I dont know for which reason the XMultiServiceFactory interface is needed. But I know that an UNO implementation can implement more then the described interfaces ... e.g. to use it internaly in combination with some implementation helpers. The other interface XScriptProviderSupplier is not described by any document service IDL. But if all office documents should be usable for scripting may be this interface should be added to css.document.OfficeDocument. Regards Andreas On 5/3/05, Christoph Lutz <[EMAIL PROTECTED]> wrote: Hi, Is there a reason why the service TextDocument doesn't support the interfaces XMultiServiceFactory and XScriptProviderSupplier *in the IDL*? Currently a TextDocument Service exports these interfaces, but that's not reflected by the IDL. best regards, Christoph __ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Crash after detach and attach toolbar using XStorable
Hello Bob ! See my comments inline ... Hi, We have a Java client which interacts with OpenOffice. One of the functions is to have OpenOffice save the document as a PDF. This works fine, except in one odd case. If the user holds down the ctrl key and double clicks on the toolbar, which detaches the toolbar, and then holds down the ctrl key down and double clicks again on the toolbar to reattach the toolbar, then the save PDF fails! Without the detach toolbar and reattach toolbar the code works fine. Do you attach/deattach the toolbar during the save operation is running or before/afterwards ... ? The office isnt ready for concurrent using of UI and API(remote) at the same time. You should define the primary use case for your application. The code looks like: xFrame.activate(); PropertyValue[] props = new PropertyValue[2]; props[0] = new PropertyValue(); props[0].Name = "FilterName"; props[0].Value = "writer_pdf_Export"; props[1] = new PropertyValue(); props[1].Name = "CompressionMode"; props[1].Value = "1"; storable.storeToURL(documentName, props); For me the call "xFrame.activate() seams to be the problem. It influence the focus handling of the frame and so you work against the specification. Normaly Frame.activate() is called within the activation/deactivation events of the window and shouldnt be used via API. After this call, OpenOffice crashes and displays the Error Report dialog. The pdf file is created but the length is 0. Please send the error report so we can have a look on that. Of course you should fill out crash report formular, so we know that this error report is related to this problem here. We are using OpenOffice 1.1.3 and Windows XP. Does any body have any ideas? Thanks Bob Crothers Net-linx Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Programming OOo as a Groupware App
Jürgen Schmidt wrote: Hi, see my comments inline Bradley Bolen wrote: Hello. I asked the following on dev@udk.openoffice.org about programming OOo as a groupware app. There is a reply that I received that I pasted below as well. The responder (btw thanks Stephan Bergmann) suggested asking on this mailing list. Please excuse me if I am sending this to the wrong list. This seemed to be the most appropriate. I am wanting to modify OpenOffice to act similar to Microsoft's Netmeeting. Specifically, I would like to modify it so that there would be a client and a server. When OO starts up it would have a dialog asking for an Impress file to serve which would also be opened as normal. The client OO would start up with a dialog that would ask for the IP address of a server. The client would then get the file and open it up. And finally, the user of the server would be able to click through the Impress document and the change of slides would also occur on the client. My basic question boils down to, is this possible using UNO or will I need to change the base code? yes, in general i would say it should be possible when you only allow read only access to the document. Everything else needs probably more changes in several places. A further important point is that server and client have the same access rights to the document. There may be exists another solution, where it's not required to share folders over the directory or install a complex infrastructure like ftp/http server. But you have to implement some helper may be ... You can use the api to make a copy of the open document (opened on the server readonly or readwrite). You should connect your client to the remote server office using UNO. Then try to locate the document you need and call "XStorable.storeToURL()" there. Use "private:stream" as URL and a parameter "OutputStream" from type "XOutputStream". Doing so you should be able to retrieve a copy of the open document from the server and save it on your local machine. Afterwards you can use the stream implementation too, to open the document on your local machine. Of course the same stream implementation must provide an XInputStream interface too. The interface method XComponentLoader.loadComponentFromURL() of the Desktop instance is your friend then. Specifically, is it possible to instantiate some object when OOo starts so that my dialog would pop a job add-on is exactly what you need here up first and then I could return control to OOo is the user decided not to use the server or start up the server otherwise? From what I understand from the SDK, UNO provides the ability to get the remote document fairly easily. I can then intercept any keystrokes and mouse-clicks on the "client" so to prevent the "client user" from moving around during the presentation. I can use urp to get messages from the "server" about mouse-clicks so that the "client" will change slides when the server does. Everything you can control via API locally can be controlled remotely as well. I expect that you can attach a listener for this kind of changes but i am not 100% sure at the moment. But the problem is that you must implement every set of functionality explicitly. There is no generic way as e.g. intercepting mouse events and transport it to the client. The reason for that: not every action which is done by the user on the server can be intercepted at one central place. And further not all functions can be reached via API. Are these valid ideas? Am I completely off? I have spent the past 3 or 4 weeks reading through the SDK trying to grasp all of the concepts. However, I would like to try to avoid any unneccessary work by going down a path that is completely wrong. From what I understand from the SDK, I can do most of the above using UNO but the opening dialog is what I am not sure about. I have looked at OOoBasic, but I really do not understand what is going on there yet. If it is possible to program this dialog, is it possible to do this with C++? Java is not my forte but seems to be what most of the documents in the SDK use and it may be better if I go that route. C++ can be used in the same way as Java. Java has the advantage that it will run on all supported platforms where as your C++ solution needs to be rebuild for each platform with the appropriate compiler. For the dialog you can use the com.sun.star.awt toolkit which is of course not the easiest task (it lacks of functionality, completeness, ...). But it is also possible to use a Basic dialog and combine this Basic dialog + some Basic macros with your C++ or Java UNO component. You can trigger your own UNO component easily from Basic. Or you use Java for the dialog and implement everything in Java with the disadvantage of a different look and fell because your Java dialog would look a little bit dif
Re: [api-dev] Crash after detach and attach toolbar using XStorable
Hello Bob! Regarding, "Please send the error report so we can have a look on that. Of course you should fill out crash report formular, so we know that this error report is related to this problem here." - I sent a report about 9:40 A.M. July 15, 2005. I have also pasted the report into this message. I've found the error report .. and it's funny. It shows a crash inside a crash, which normaly shouldnt be possible. An exception from this rule would be, if you saw the error report dialog more then once and used only the last one for sending. Do you remember, how often the error report dialog cames up for one crash ? BTW: I've sended the error report to our VCL team. It seams to be a problem there. I entered "abc". Detached the toolbar. Attached the toolbar. Entered "xyz". Our client Java code then did XStorable.storeToURL(documentName, properties); The properties had a length of 2. Properties[0].name = Overwrite Properties[0].value= true Properties[1].name = FilterName Properties[1].value= writer_pdf_Export Currently there is no fix available ... and further there is no workarund from our side possible. But may be you can do something: a) Dont use the UI of the office if you script via remote UNO. Question: Why attach/deattach of a toolbar manually done by an user is needed in parallel to scripting the office via UNO ? b) Dont use the PDF filter in this scenario. Because the PDF filter is bound to the UI of the office more then any other filter. And so you do something "dangerous" here .-) Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Crash after detach and attach toolbar using XStorable
Hello Bob ! Regarding, "Do you remember, how often the error report dialog cames up for one crash?" - one time. ??? The stacktrace show another sceanrio. Regarding, sending the error report to our VCL team - thanks Andreas. But fixing of this bug needs some time ... so I cant say anything about the timeframe. And currently there is no workaround ... excepting dont usingthe UI of the office (which isnt an option for you). So you have to live with this situation for a while :-( Regarding the using both UNO and the UI - that is how our system works. We have a Java application which houses OpenOffice. The Java application, starts OpenOffice, shows/hides, inserts text, retrieves the document, stores the document in a database, and uses OpenOffice to create a PDF among other tasks. We use UNO to drive OpenOffice from our application. The user uses the OpenOffice UI to do his work. Our system requires both parts. We can't just remove UNO. But how do you synchronize using the UI and storing documents via API ? Further you should use the API very carefully. E.g. you should make sure that your java client cant be killed and the office stands alive. Every click to the UI will kill the office because dead UNO objects are referenced inside the office ... As I said: not the best idea. But it can work, if you know all the "possible problems" and prevent your code against these. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OOo C++ FAQ ?
Galmes Pierre-Andre wrote: Hello, Is-there a kind of FAQ about all the C++ questions that someone may have (like for example the Try-catch problem in gcc) ? Should we use the codesnippets page for that ? Would it be an idea to create a FAQ page ? As Stephan already described .. the CodingGuidelines document seams to be your frined. For problems related to the OOo API you should have a look on "http://api.openoffice.org/faq.html"; or for general problems with OOo on "http://www.openoffice.org/faq.html";. Regards, Pierre-André Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OOoBasic : Open a new base document
Laurent Godard wrote: Hi paolo just randomly tried with "private:factory/sdatabase" and... it works!! :-) (OOo 1.9.128) thanks i've tried during my long train trip and found this but not randomly :) randomly, i tried sbase and not sdatabase btw, the info is stored in /share/registry/modules/org/openoffice/TypeDetection/Filter You are right ... these special URLPattern's are registered for filters. But the right place to find out, how an empty document related to an office module can be created, is our configuration file "Setup.xcu". You can find it inside your installation on "share/registry/data/org/openoffice/Setup.xcu" and "share/registry/modules/org/openoffice/Setup/Setup-xxx.xcu" There you will find a property "ooSetupFactoryEmptyDocumentURL", where every registered office module define it's own "Empty Document URL". Thanks again paolo Laurent Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Simple question - How to maximize a window
Andrew Jensen wrote: I have searched the SDK, spent a lot of time moving up and down paths using Xray, and keep coming up dry. All I want to do is create a maximized window, actually not create it, I wan't to maximize an open window. Not one that is the same size as the desktop, a Maximized window state. If there really is no such thing in the API, then how do I get a Hwnd, I saw mention of it once but now can't find it, to a top level window so that I can call a win32 function. Kind of hate to make this OS specific however. You are right ... currently there is no function on the window API to maximize nor minimize a toolkit window. May be we should change that next time it's possible. But you can retrieve the native window handle (e.g. HWND on windows). Cast the window to the interface css.awt.XSystemDependentWindowPeer and call it's method getWindowHandle(). The parameter ProcessId can be ignored (use an empty array) ... but the second parameter SystemType must be from type css.lang.SystemDependent. The return value itselfs depend from the used SystemType parameter. Please read the document of the interface. Here a basic macro, which shows the needed steps: sub maximize frame = StarDesktop.getActiveFrame() window = frame.getContainerWindow() handle = window.getWindowHandle(dimarray(), 1) ' 1=WIN32 msgbox handle end sub Any help would really be appreciated. From: OpenOffice.org 2.0 Office Suite Guide to New Features *Quote:* testtool: new commands to min/max/restore windows Quality Assurance Added the following methods for Document-Windows + .Close + BOOL .IsMax + BOOL .IsMin + BOOL .IsRestore + .Minimize + .Maximize + .Restore. Drew Jensen Guanahani - not Ahmedabad...only missed it by that much.. ~ Chris. Columbus Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Simple question - How to maximize a window
Andrew Jensen wrote: .-) My code snippet was an example only ... and I've shown you a way, which isnt the preferred one for myself .-) The problem behind getActiveFrame() / getCurrentController() is the dependenc against the focus. If the application is loosing it's focus it can happen that your macro doesnt work any longer. The better way is to make it explicitly. Every macro should "know it's frame/controller/model" on which it can work. E.g. you can create your own frame - load the right component into it and work with it. Or you can use the desktop to iterate over all open document frames and ask for some properties to find out, which of these frames/models can be interesting for you. At least it depends from your requirements. On the other side you can work with ActiveFrame/CurrentController ... but you should be aware that it can fail .-) Regards Andreas FYI, I changed one line frame = thisComponent.CurrentController.Frame and it is working for the Data Etnry form also. Thanks again Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] problem with OfficeBean and JInternalFrame
Markus Plessing wrote: Hello Roberto, Roberto Battistoni schrieb: I'm trying to add an OfficeBean to a JInternalFrame, but Oo start in a without-frame window in a full-screen mode, not in the JInternalFrame. Why this? [...] The Java-Window has to provide a system window handle using a java.awt.Canvas and some JNI-Methods. For further information see the corresponding part of the DevGuide : 6.1.7 Java_Window_Integration http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml That's true ... The implemented JNI-methods retrieves the system window handle from the java.awt.Canvas ... but they work only in case the java-windows was already shown. Otherwhise they are not able to return such window handle. But if then the office is asked to create a new document window it get's 0 as parent instead of a valid window handle. And so it creates a window on the system desktop instead of creating a child window placed into the java environment. Two solutions: - make sure that your java window was shown before you create the office document - wait for the fix inside the bean (which is currently in progress) Regards Andreas Greetings Markus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] quickstarter / storeToURL problem (python)
Daniela Garling wrote: Please dump the URL you created on demand to the console. May be it will be generated wrong in such case. As next try you should dump the error message given by the catched exception. May be it shows the problem already. Regards Andreas Hello list, I have encountered a problem that I cannot understand no matter how hard I try: I have a python app that calls openoffice to create a writer document. it then saves it to disk using model.storeAsURL where model is the current document. So far so good. Then I want to extract the raw text from the document using this function: # code snippet def rawText(self, model, storepath): cwd = systemPathToFileUrl( getcwd() ) makedir(self) filename = os.environ['TEMP'] + '\\' + storepath + '.txt' storeUrl = absolutize( cwd, systemPathToFileUrl(filename) ) filterName = "Text (Encoded)" storeProps = PropertyValue( "FilterName" , 0, filterName , 0 ), model.storeToURL(storeUrl, storeProps) # end of code snippet ## now - this code works. everytime. EXCEPT for, when i just restarted the quickstarter. so the way to reproduce the problem is: quit quickstarter. start quickstarter. start python app. initiate creation of document. save document to disk, thereby initiate extraction of rawtext. -> ErrorCodeIOException the way to "solve" this problem is: quit python app. start python app. initiate creation of document. save document to disk, thereby initiate extraction of rawtext. -> success. i suspected it might have something to do with how fast the office gets done with the saving of the document and all and tried working around that by using this code: # code snippet ### def rawText(self, model, storepath): cwd = systemPathToFileUrl( getcwd() ) makedir(self) filename = os.environ['TEMP'] + '\\' + storepath + '.txt' storeUrl = absolutize( cwd, systemPathToFileUrl(filename) ) filterName = "Text (Encoded)" storeProps = PropertyValue( "FilterName" , 0, filterName , 0 ), try: open(os.environ['TEMP'] + '\\'+ storepath, 'r') model.storeToURL(storeUrl, storeProps) except ErrorCodeIOException: time.sleep(2) rawText(self, model, storepath) # end of code snippet ## to no avail though. :/ if there's anybody with any explanation or workaround or even fix for this problem, please respond. Thanks in advance, Daniela - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] quickstarter / storeToURL problem (python)
Daniela Garling wrote:
I don't quite know how to. What I do with python is a try: something
except ErrorCodeIOException: do something else.
Now, how would i "catch" the exception in order to get to its ErrCode?
My debugger tells me that
ErrorCodeIOException is a class-object consisting of a __doc__ string
(which is None), __module__ (which is
"uno"), __pyunointerface__ ("com.sun.star.task.ErrorCodeIOException"),
__pyunostruct__ ("com.sun.star.task.ErrorCodeIOException"),
and typeName (also a string "com.sun.star.task.ErrorCodeIOException").
No ErrCode to be found. What am I doing wrong?
I dont know how exceptions are handled in python ...
But on other languages (e.g. C++) you write the following one:
try
{
doSomething();
}
catch(const ErrorCodeIOException& ex)
{
long nError = ex.ErrCode;
printf("error = %d\n", nError);
}
As to the idea of inserting a little break between saving the document
to disk and extracting it's raw text:
I had implemented a little test to try that. the function rawText would
try "storeToURL" and upon an errorcodeioexception
I had it wait for 2 seconds before calling itself again and so trying to
extract it again. I had it running for a couple of
minutes to no avail. :/
Implementing a "timeout-retry" scenario makes no sense.
Because it will run into trouble everytime you:
a) start the executable on another machine
b) or your machine is used by other processes too
etcpp.
Doing so can be a workaround only.
Ciao
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Document is loaded in a background window
Andreas Schlüns wrote: This feature(!) was requested by the community ... but may be sligthly different from the scenario you describe :-) a) The old bahviour of OOo was to call Frame.getContainerWindow().toFront() after loading of the document was finished. b) But some poeple requested to change that. The reason: If you load a big document (which needs several seconds or minutes) ... may be the user select another window of its desktop and may be started working on it. But then these poeple was displeased by the OOo window, which interrupts working on the other window. So the request was the following one: OLD CODE: loadComponentFromURL() window = createWindow() load() window.toFront() NEW CODE: loadComponentFromURL() window = createWindow() window.toFront() load() After looking into the code I must correct myself. The mentioned fix was tried, but disabled afterwards. So the current behaviour of the master will be: loadComponentFromURL() window = createWindow() load() window.toFront() BTW: Issue ID for the community request was #19976#. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re: Load Excel file (.xls)
Vincenzo Giuliano wrote:
Vincenzo Giuliano wrote:
Hi ALL,
my name is Vincenzo. I have a problem.
I try to load excel file (.xls) via java code:
PropertyValue[] props = new PropertyValue[2];
props[0] = new PropertyValue();
props[0].Name = "FilterName";
props[0].Value = "MS Excel 97";
props[1] = new PropertyValue();
props[1].Name = "Hidden";
props[1].Value = new Boolean(false);
XComponent comp=
xcl.loadComponentFromURL("path_file_.xls","_default",FrameSearchFlag.ALL,props);
But the XComponent interface is null.
So I retry with this code:
XComponent comp=
xcl.loadComponentFromURL("path_file_.xls","_default",FrameSearchFlag.ALL,*new
PropertyValue[0]*);
The file is loaded in Writer/Web.
Someone can tell me the why?
Because it's may be an HTML file in real (with wrong extension) ?
Thank you ALL.
In Path>/share/registry/modules/org/openoffice/TypeDetection/Filter/fcfg_calc_filters.xcu
the "MS Excel 97" Filter exists.
Moreover, if i try to start the file with double click, Calc load the
file in tranquil way.
If you make a double click (I guess you make it inside your windows
explorer ... right ?) it calls not soffice.exe ... it calls scalc.exe.
And this special binary calls "soffice.exe -calc " internaly.
So you preselect the calc application.
And then your file inst loaded as "MS Excel 97" inside calc.
It's opened then as "calc_HTML_WebQuery" instead.
Pleas make sure that your file is a real xls file.
Regards
Andreas
PS: You can try the following ... which is a "workaround" only :
PropertyValue[] props = new PropertyValue[3];
props[0] = new PropertyValue();
props[0].Name = "FilterName";
props[0].Value = "MS Excel 97";
props[1] = new PropertyValue();
props[1].Name = "Hidden";
props[1].Value = new Boolean(false);
props[2] = new PropertyValue();
props[2].Name = "DocumentService";
props[2].Value = "com.sun.star.sheet.SpreadsheetDocument";
XComponent comp=
xcl.loadComponentFromURL("path_file_.xls","_default",0,props);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re:Re: Re: Load Excel file (.xls)
Vincenzo Giuliano wrote:
Hi ALL,
I come to a conclusion.
This code start a .xls file (if it exists).
I accept any advice.
public class LoadExcel {
/[EMAIL PROTECTED] null if url don't exists*/
public static XModel startExcelFile(String urlExcelFile)throws
java.lang.Exception{
/**Bootstrap*/
com.sun.star.uno.XComponentContext contestoRemoto =
com.sun.star.comp.helper.Bootstrap.bootstrap();
System.out.println("Connected to a running office ...");
com.sun.star.lang.XMultiComponentFactory serviceManager =
contestoRemoto.getServiceManager();
String available = (serviceManager != null ? "available" : "not
available");
System.out.println( "remote ServiceManager is " + available );
/***/
Runtime r = Runtime.getRuntime();
Process p = r.exec("soffice -calc "+urlExcelFile);
Does this solve your problems realy ?
If it's so - please make realy sure your file is a real xls - file.
Your code isnt realy a fix ... it has some other disatvantages.
Please use the normal API of OOo - not the command line.
As Jürgen already mentione: please file an issue on OOo containing your
test document (if it's not private).
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re: Re:Re: Re: Load Excel file (.xls)
Vincenzo Giuliano wrote: Hi Andreas, I already answered in another mail. The file was corrupted probably or was not maybe an excel file in real. I paste the mail below. I've readed this email too. But I've tried to mention that using the command line in combination with using the UNO API isnt realy an option. The command line of OOo supports very(!) simple requests only. You should prevent it and use the OOo API instead. Especialy "Process.execute(soffice -calc )" can be written as: PropertyValue[] lArgs = new PropertyValue[1]; lArgs[0] = new PropertyValue(); lArgs[0].Name = "DocumentService"; lArgs[0].Value = "com.sun.star.sheet.SpreadsheetDocument"; xDoc = xDesktop.loadComponentFromURL(url, "_default", 0, lArgs); Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Java Snippet Suggestion: how to convert documents - please review
Hello Tobias,
You shouldnt post "a complete application" as code snippet.
It's better to show some parts of you approach only.
E.g. loading a CSV file, exporting any file to PDF etcpp.
See my further comments inline ...
Hi ML,
I want to add another code snippet. This snippet bootstraps an
OpenOffice and converts a specified document to a specified format.
Here the code. If noone has suggestions, I will post it as a snippet
next week.
Greetings, Tobias
-%<-
package de.twc.oocom.snippets;
import com.sun.star.beans.PropertyValue;
import com.sun.star.comp.helper.Bootstrap;
import com.sun.star.comp.helper.BootstrapException;
import com.sun.star.frame.XComponentLoader;
import com.sun.star.frame.XStorable;
import com.sun.star.io.IOException;
import com.sun.star.lang.XComponent;
import com.sun.star.lang.XMultiComponentFactory;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
public class ConvertDocument {
public ConvertDocument(){
// Empty Constructor
}
// The file that should be processed, e.g. "/tmp/hello_world.ods"
private String source_File = "/home/tobias/test.odt";
// The file that is the target of a conversion, e.g. "/tmp/hello_world"
private String target_File = "/home/tobias/test.pdf";
// Format of the target_File. This snipped allows "pdf", "doc", "xls"
private String conversion_Format = "pdf";
// Value not really needed
private String ooport = "9000";
// Commandline parameter can equal these value
public final static String CONVERT = "-convert";
public final static String[] EXPORTS = { "writer_pdf_Export",
"calc_pdf_Export", "draw_pdf_Export", "impress_pdf_Export" };
public final static String DOC_EXPORT = "MS Word 97";
public final static String XLS_EXPORT = "MS Excel 97";
// OpenOffice Desktop
Object desktop = null;
/**
* Main method. For commandline start values see method
* setCommandlineArgs(args).
*
* @param args
*/
public static void main(String[] args){
ConvertDocument myOOComNG = new ConvertDocument();
myOOComNG.convertDocument();
}
/**
* This method sets the import values for .csv files.
*
* @return
*/
public PropertyValue[] csvImportProperties(){
PropertyValue[] csvPropertyValue = new PropertyValue[2];
PropertyValue xProperty = new PropertyValue();
xProperty.Name = "FilterName";
xProperty.Value = "Text - txt - csv (StarCalc)";
csvPropertyValue[0] = xProperty;
xProperty.Name = "FilterOptions";
xProperty.Value = "44,34,0,1,1/1";
csvPropertyValue[1] = xProperty;
return csvPropertyValue;
}
/**
* This method collects all properties for the document an concatenates
* them.
*
* @param myProperties
* @return
*/
private PropertyValue[] constructProperties(PropertyValue[]
myProperties)
{
// Getting properties for .csv files
PropertyValue[] csvPropertyValue = csvImportProperties();
// Initializing the properties
PropertyValue[] documentProperties
= new PropertyValue[myProperties.length +
csvPropertyValue.length];
for(int i = 0; i < myProperties.length; i++){
// Load myProperties.
documentProperties[i] = myProperties[i];
}
if (source_File.toLowerCase().endsWith(".csv")){
// If source_File is a .csv file, csv import Properties are
added
for(int i = 0; i < csvPropertyValue.length; i++){
documentProperties[myProperties.length + i] =
csvPropertyValue[i];
}
}
return documentProperties;
}
/**
* This method converts documents to other formats.
*/
private void convertDocument()
{
// Constructing the document properties
PropertyValue[] myProperties = new PropertyValue[1];
PropertyValue xProperty = new PropertyValue();
xProperty.Name = "Hidden";
xProperty.Value = new Boolean(true);
myProperties[0] = xProperty;
PropertyValue[] documentProperties =
constructProperties(myProperties);
// Open document
XComponent openDocument = openDocument(documentProperties);
XStorable xStorable = (XStorable)
UnoRuntime.queryInterface(XStorable.class, openDocument);
// Set properties for conversions
documentProperties = new PropertyValue[2];
PropertyValue bProperty = new PropertyValue();
bProperty.Name = "Overwrite";
bProperty.Value = new Boolean(true);
documentProperties[0] = bProperty;
bProperty = new PropertyValue();
bProperty.Name = "FilterName";
// Conversion starts
if (conversion_Format.equals("pdf")) {
// Convert to pdf
for (int i = 0; i < EXPO
Re: [api-dev] Java Snippet Suggestion: how to convert documents - please review
Tobias Krais wrote:
Hi Andreas,
You shouldnt post "a complete application" as code snippet.
It's better to show some parts of you approach only.
yes and no. For one part I agree. If you are an expert, it is useful for
you to see only the relevant part of an application.
But I disagree because I am a newbie. And I waste 90% of my time with
finding out the conditions for code snippets and how to get them to
work. And you can imagine, this work is really discouraging.
I suggest a solution: I post the relevant part of the code as a snippet
and add a link to my homepage where you can find a sample application
for the snippet. Is this useful?
Do it as you like ...
At least my comment on this was not a "must" - it was a hint only.
But I know from my own experience: if an example shows more then two
facts at the same time, the "newbie" does not see the important things.
Trying all possible PDF export filters and catching occuring exceptions
isnt realy "good style" .-)
The better approach:
com.sun.star.frame.XModuleManager xMM =
(com.sun.star.frame.XModuleManager)UnoRuntime.queryInterface(
com.sun.star.frame.XModuleManager.class,
xSMGR.createInstance("com.sun.star.frame.ModuleManager"));
Here I have my first problems. Please give me a hint: what is the type
of xSMGR? How can I creat xSMGR? (I'm sure it is a very simple answer,
but I already searched about 4 hours for the solution...).
It's the remote service manager of the office cou can use to create
needed UNO services. In your example you used the following code to
create the Desktop service:
XMultiComponentFactory xRemoteServiceManager
= xRemoteContext.getServiceManager();
Object desktop = null;
try
{
desktop = xRemoteServiceManager.createInstanceWithContext(
"com.sun.star.frame.Desktop", xRemoteContext);
}
...
So my example must be rewritten as:
XModuleManager xMM = (XModuleManager)UnoRuntime.queryInterface(
XModuleManager.class,
xRemoteServiceManager.createInstanceWithContext(
"com.sun.star.frame.ModuleManager",
xRemoteContext));
String sOOoApp = null;
try{
sOOoApp = xMM.identify(openDocument);
}catch(com.sun.star.frame.UnknownModuleException)
{
...
}
// Now you know the application name of this document
// e.g. "com.sun.star.text.TextDocument" for writer
// And you can select the right filter:
String sPDFExportFilter = null;
if (sOOoApp.equals("com.sun.star.text.TextDocument"))
sPDFExportFilter = "writer_pdf_Export";
else
...
This is very good! Thank you, I will do it this way as soon as I find
the xSMGR.
see before .-)
b)
Construction of URL's isnt realy platform independend here. You should
the JAVA classes File/URL/URI to create real URL's.
But be aware of a bug inside these JAVA classes. They construct file
URL's like "file:/test/file.txt", which does not represent valid file
URLs. You have to establish a workaround for that and convert "file:/"
hardly to "file:///".
On the other side I currently dont know, if OOo accepts such "wrong
formated" URL's too and convert it internaly .-)
Well its working -> I think OO will accept it. But I will use following
code for the snippet:
-%<-
public String createUNOFileURL(String filelocation)
{
String myUNOFileURL = null;
java.io.File newfile = new java.io.File(filelocation);
try {
myUNOFileURL
= newfile.toURL().toString().replace("file:/", "file:///");
}
catch (MalformedURLException e) {
System.out.println(e.getLocalizedMessage());
}
return myUNOFileURL;
}
Better use the helper service ... as Stephan Bergmann mentioned !
-%<-
}
catch(Exception e)
{
System.out.println("OpenOffice runs, but error opening
document:");
System.out.println(e.getLocalizedMessage());
}
if (openedDocument == null) {
System.err.println("I found the document but cannot open
it...");
System.exit(-4);
System.exit() isnt realy an option, if you work remote with OOo using
UNO. Your JAVA process will be killed hardly - fine . But the OOo
instance will stay alive inside memory ... Furhtermore it might contain
dead UNO objects (forgotten JAVA listener etcpp). And if you use this
office instance from it's normal UI it can happen that it crashes by
using these dead objects.
Solution:
Terminate the office from JAVA before you call exit()
If I understand right, this will exit all my offices or just this
instance. I even have no xDesktop -> I think I cannot add a
terminateListener. Am I right?
You used the desktop service already. It's the component you called
"loadComponentFromURL()" on it. And this object can do some
Re: [api-dev] Connecting two OpenOffice Process
Vincenzo Giuliano wrote: Hi ALL, this is my problem: I started up OpenOfficeProcess on remote host, then I started up OpenOfficeProcess on my computer. I load a file on remote host and I take the XModel reference. I want seen on my computer the document, how can I do? I try to do this XFramesSupplier xfs = (XFramesSupplier)UnoRuntime.queryInterface(XFramesSupplier.class,desktopOnMyComputer); XFrames xf = xfs.getFrames(); xf.append(frameRemoteDocument); frameRemoteDocument.getContainerWindow().setVisible(true); frameRemoteDocument.getComponentWindow().setVisible(true); but it has not effect. Not really right ... It has an effect - on the remote PC. Because the window resists there and you show it there. You use an UNO reference to a remote object. All operations will be forwarded to the rmeote object (on the other PC) and executed there. If you whish to do something on a local object - you have to create this object localy too. In your case you have to create an XWindow localy and combine it with the remote retrieved XFrame BUT THAT CANT WORK .-) Sorry. The problem here is reasoned by the internal implementation of OOo. Internaly it does not use UNO completly. So it requires a C++ pointer to a VCL::Window class instead of using the XWindow UNO reference. And that's why you wont be able to make such things if UI is involved. And sorry again. I do not know when OOo will be ready for these. It's a huge task and cant be made in some months. So you have to find another solution for your problem. Thanks in advance. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Java: adding functionality to newly created menu item
Tobias Krais wrote: Hi Matthias, Menu commands are command strings that are handed over to the so called Dispatch Framework. You can place "internal" commands there and then some OOo code will be called or (if an "interceptor" is placed into OOo) also some "external" code. You can also place "external" commands there that can trigger code you provide in your component. To make OOo call such "external" code you have to use commands with your own naming scheme and implement and install a so called "protocol handler" that handles commands using the scheme. All this is described in the Developers Guide in the chapters about Dispatching and Add-Ons. Up to now I read a lot in the Dev-Guide. Please let me ask you some further questions whether I understood the Dev-Guide right and my concept is OK. What I want to do after starting OO from a Java application: 1. adding a menu and toolbar item with the commandURL "vnd.twc.oo.oocom:SaveACopy" (I did this already and the menu item is grey - it is not known up to now). The menu item is gray, because there is no code bound to this command. You have to register a ProtocolHandler or establish an Interceptor for this URL. But an Interceptor is normaly designed to intercept (and overwrite) existing functionality ... not to bring in new functions. So the ProtocolHandler mechanism is the best way doing this. 2. after clicking on the menu item, I want start external code that pops up a window with a selection menu. After selecting and clicking OK, the selection is printed on System.out.println(). After closing OO the command URL should be no more available for OO. Showing the UI is no problem. System.out.println() can be a problem (at least on windows). Because there OOo supress all command line activity. You wont see anything .-) But for me it seams that this println() statmenet is temp. solution only ... isnt it ? Complete removing of this command after OOo was restarted can be reached only by patching the configuration of the office during runtime. Because a ProtocolHandler can be registered inside our configuration only. And then it exists after an office restart too ... So you have to deregister it manually. Our dispatch framework should be ready for that. Because such "live-deployment" of ProtocolHandler objects will be supported. The only thing which can happen is that the current view wont be updated immediatly. May be only new views will reflect the changed menu. Solution possiblity for 2.: As far as I read, using Jobs as described in 4.7.2 is not a good solution, because I can't display a user interface from synchronous job. You can do that ... but if such UI is e.g. written in JAVA and not using e.g. basic dialogs you will hinder the office on repainting itself .-) A asynchronous job has problems with model interfaces so I shouldn't use it. Which problems do you mean ? It can happen that a Job does not get a model reference ... but that depends from the fact, that jobs can be bound to events, which are not bound to models in general. So the job get it's context as set of parameters. And one of these parameters can be the model .. or the frame ... or any other resource. Solution possiblity for 2.: Other solution is to use protocol handlers. But if I understood right, I have to install them and they will be available after closing OO. If there is no other solution, I have to check at startup whether the commandURL is availible. If not, can I install a protocol handler during runtime from my java application? (In this case I have to accept that the commandURL will be available after closing OO.) I'm not sure how do you whish to "establish" all your features inside OOo. As an AddOn ... or using basic ... or JAVA-remote ? a) If you use an AdddOn, you are right. Such Protocolhandler will live as long as the AddOn-installation for this component exists. b) But if use JAVA-remote you can add/remove such ProtocolHandler during an instance of OOo runs. But believe me: patching of the ProtocolHandler configuration is an easy task (and will work of course) ... but registration of an UNO component at runtime isnt so easy .-) And I know - removing of such component at runtime isnt realy possible in general. Because you cant be sure that such ProtocolHandler instance is not cached (e.g. by the toolbar implementation) ! Are there other solutions? I dont see a realy good solution. Sorry. On the other side: is it realy needed to make such "transient changes" on a running OOo instance ? Or wouldnt be better to install an AddOn and enable/disabe the corresponding menu entries on demand ? Currently I dont see any use case, which would require such feature. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas --
Re: [api-dev] Java: adding functionality to newly created menu item
Tobias Krais wrote:
Hallo Andreas,
To make OOo call such "external" code you have to use commands with your
own naming scheme and implement and install a so called "protocol
handler" that handles commands using the scheme. All this is described
in the Developers Guide in the chapters about Dispatching and Add-Ons.
1. adding a menu and toolbar item with the commandURL
"vnd.twc.oo.oocom:SaveACopy" (I did this already and the menu item is
grey - it is not known up to now).
The menu item is gray, because there is no code bound to this command.
You have to register a ProtocolHandler for this URL.
[...]
b) But if use JAVA-remote you can add/remove such ProtocolHandler during
an instance of OOo runs. But believe me: patching of the ProtocolHandler
configuration is an easy task (and will work of course) ...
Although it sounds very good, I have no idea and found no hints how to
do this. I have to fall back to your second solution. Or may be you have
some hints for me...
You have to use the configuration API of OOo directly and change the cfg
package "org.openoffice.Office.ProtocolHandler".
Please read the Developers Guide to get further informations.
registration of an UNO component at runtime isnt so easy .-)
And I know - removing of such component at runtime isnt realy possible
in general. Because you cant be sure that such ProtocolHandler instance
is not cached (e.g. by the toolbar implementation) !
I did now following:
-%<
// Conditions:
// opened OO Document
// XMultiComponentFactory xRemoteServiceManager
XMultiServiceFactory xMultiServiceManager = (XMultiServiceFactory)
UnoRuntime.queryInterface( XMultiServiceFactory.class,
xRemoteServiceManager );
Object oProtocolHandler = xMultiServiceManager.createInstance(
"de.twc.oocom.SaveACopy" );
// get the XDispatchProvider and XInitialization interfaces
XDispatchProvider xDispatchProvider = (XDispatchProvider)
UnoRuntime.queryInterface(
XDispatchProvider.class, oProtocolHandler );
XInitialization xInitialization = (XInitialization)
UnoRuntime.queryInterface(
XInitialization.class, oProtocolHandler );
-%<
The Object oProtocolHandler always is null. If I understand right, I
need a class de.twc.oocom.SaveACopy. I created it and you can find it at
the end of the mail (it is nearly the same as
http://kingyo.tutms.tut.ac.jp/~toshi/StarSuite/Chap4/EX4710/).
How can I tell UNO where to find the class de.twc.oocom.SaveACopy?
You have to register it inside the ooo/program/services.rdb file using
the tool unopkg tool (provided by OOo also).
But .. ups ... I've forgot: you cant change the installations of you
client PCs ...
But an UNO service must be registered also .-)
Why you dont use a central installation of OOo, which can be patched
with your extensions, and is used from many other client installations ?
Then there is no need for you to make so many "transient" changes on an
OOo installation ... which btw. seams to be impossible for me now.
Greetings, Tobias
-%<-
package de.twc.oocom;
import com.sun.star.beans.PropertyValue;
import com.sun.star.frame.DispatchDescriptor;
import com.sun.star.frame.XDispatch;
import com.sun.star.frame.XDispatchProvider;
import com.sun.star.frame.XFrame;
import com.sun.star.frame.XStatusListener;
import com.sun.star.lang.XInitialization;
import com.sun.star.lang.XServiceInfo;
import com.sun.star.lib.uno.helper.ComponentBase;
import com.sun.star.uno.UnoRuntime;
import com.sun.star.uno.XComponentContext;
import com.sun.star.util.URL;
/** SaveACopy service implementation */
public class SaveACopy extends ComponentBase
implements XServiceInfo, XDispatchProvider, XInitialization
{
private XComponentContext xContext;
private XFrame xFrame;
/** Dispatch object as inner class */
class OwnDispatch implements XDispatch {
/** take over all necessary parameters from outside. */
public OwnDispatch(XComponentContext context, XFrame frame) {
xContext = context;
xFrame = frame;
}
/** execute the functionality, which is described by this URL. */
public void dispatch(URL aURL, PropertyValue[] lArgs) {
System.out.println("Hallo Dispatcher Welt!");
}
/** register a new listener and bind it toe given URL. */
public void addStatusListener(XStatusListener l, URL url) {
}
/** deregister a listener for this URL. */
public void removeStatusListener(XStatusListener l, URL url) {
}
}
/** initialize a new instance of this class with default values. */
public SaveACopy( XComponentContext context ) {
xContext = context;
}
//
/** XInitialization implementation */
public void initialize(Object[] object)
throws com.sun.star.uno.Exception {
if
Re: [api-dev] XComponentLoader event onload
Antoine POURCHEZ wrote:
Hello,
I want to load and next update an ODT in a java program. To do that, i
write this code :
Object vDesktop = OoBootstrap.createDesktop();
XComponentLoader vCompLoader = (XComponentLoader)
UnoRuntime.queryInterface(XComponentLoader.class, vDesktop);
String vUrl = "_file://".concat(((File_)
pSrc).toURL().toExternalForm().substring(5));
PropertyValue vProps[] = new PropertyValue[1];
vProps[0] = new PropertyValue();
vProps[0].Name = "Hidden";
vProps[0].Value = Boolean.TRUE;
Object vDocSrc = vCompLoader.loadComponentFromURL(vUrl,
"_blank", 0, vProps);
XFrame vFrameDoc = ((XModel)
UnoRuntime.queryInterface(XModel.class,
vDocSrc)).getCurrentController().getFrame();
XDispatchHelper vDipatchHelper =
(XDispatchHelper)UnoRuntime.queryInterface(XDispatchHelper.class,
OoBootstrap.createService("com.sun.star.frame.DispatchHelper"));
vDipatchHelper.executeDispatch((XDispatchProvider)UnoRuntime.queryInterface(XDispatchProvider.class,
vFrameDoc), ".uno:UpdateAllIndexes", "", 0, null);
In some big documents, this generate a crash of openOffice : i think
that the document is not totaly load when "executeDispatch" is execute.
The document is loaded completely after loadComponentFromURL() returned
the model. But might be there are some asynchronous layout routines.
On the other side such asynchronous layout must deal with the situation
that it will be disturbed from outside. And further you loaded the
document with HIDDEN=TRUE so there is no need for such operations after
loading.
For me it looks like a "simple .-)" bug. If it can be reproduced by you
with some special documents, please file an issue attaching one or two
test documents.
Can XComponentLoader generate an event when all the document is load?
There is already such event. But it's not generated by the component
loader itself. It's generated by the document, which was loaded and will
be broadcasted by another singleton instance named
com.sun.star.frame.GlobalEventBroadcaster (which implements the
interface css.document.XEventBroadcaster.
The callback css.document.XEventListener.notifyEvent() contains a
reference to the model. For loading (or creating empty) documents exists
different events.
OnNew => for creating a new empty (visible) doc
OnLoad => for loading an existing doc (visible) from disc
OnCreate => for creating an empty (hidden) doc
OnLoadFinished => for loading an existing doc (hidden) from disc
Thank you.
Antoine POURCHEZ
[EMAIL PROTECTED]
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] New component: instead of ".uno:SaveAs" ".uno:SaveTo"
Tobias Krais wrote: Hi again, I now had success with creating my first component. I can register it and use in in the menus. Thank you all! But now I want to write a second component: it should be the same as already exists: ".uno:SaveAs". But the functionality should be different: it should store the object's persistent data to a URL and continues to be a representation of the old URL. It is the same difference as in XStorable.storeAsURL() and XStorable.storeToURL(). My question: is it the easiest way to develop a complete new component or can I reuse the main parts of ".uno:SaveAs"? You can reuse main parts of ".uno:SaveAs" ... if you link your code against the core libraries of OOo .-) But there is no way doing so in case you wish to use the UNO API. So you have to do the full implementation again. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] How to tell a component the current XComponent?
Tobias Krais wrote: Hi together, I created my first component and have now a big problem: -%<- private XComponent openDocument = null; [...] // Querying for the interface XPrintable on the loaded document XPrintable xPrintable = (XPrintable) UnoRuntime.queryInterface(XPrintable.class, openDocument); -%<- I want to print the current document, but I don't know how to tell the component the XComponent the user used when clicking on the item of the menu. Can anybody tell me how to do this? Or generally: how to give variables to components? If you implemented a ProtocolHandler (e.g. as part of an AddOn), which is used within a menu/toolbar click, you will be queried for an option al interface "XInitialization". If this optional interface is supported it's called and the frame (where the menu/toolbar exists) is provided there as first parameter. Such frame can be used then to get access to the controller/model. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] DocumentConfiguration
Tuomas Räsänen wrote:
Hi again,
My goal is to prevent user from using default styles in textdocs.
Apparently those default styles cannot be "disabled", so I need to make
everything manually. One thing I have to do is to remove accelerators
modifying styles. (e.g. CTRL + 1 = Heading 1).
I tried to remove that accelerator with the code below, but nothing
happened. CTRL+1 was still working. What did I do wrong?
--
Object conf =
xRemoteServiceManager.createInstanceWithContext("com.sun.star.ui.ModuleUIConfigurationManagerSupplier",
xRemoteContext);
XModuleUIConfigurationManagerSupplier confMngrS =
(XModuleUIConfigurationManagerSupplier)UnoRuntime.queryInterface(XModuleUIConfigurationManagerSupplier.class,
conf);
XUIConfigurationManager xConfMngr =
confMngrS.getUIConfigurationManager("com.sun.star.text.TextDocument");
Object shortcutConfManager = xConfMngr.getShortCutManager();
XAcceleratorConfiguration ac =
(XAcceleratorConfiguration)UnoRuntime.queryInterface(XAcceleratorConfiguration.class,
shortcutConfManager);
KeyEvent[] keys = ac.getAllKeyEvents();
ac.removeCommandFromAllKeyEvents(".uno:StyleApply?Style:string=Heading
1&FamilyName:string=ParagraphStyles");
--
And is there easier way to achieve my goal? Can I include a
configuration file in my template to setup accelerators for my document?
( just like menubar.xml ) And if, where should I put it? There is
configuration file for global and module accelerators
($OFFICE_DIR/share/config/soffice.cfg/global/accelerator/en-US/default.xml
and e.g.
$OFFICE_DIR/share/config/soffice.cfg/modules/swriter/accelerator/en-US/default.xml)
for the whole OpenOffice but in template files there is only
/configuration2/menubar/menubar.xml)
The path to a document-accelerator configuration inside a document is
"Configurations2\accelerator\current.xml"
This path is fixe, because there is no need to differ between modules
and locales.
Curious regards,
Tuomas Räsänen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Restarting a frozen OOo
Kay Ramme - Sun Germany - Hamburg wrote: see my comments inline ... Tobias, Tobias Krais wrote: just now my OOo had a dealock again. And I followed your advice. Here is the comandline output: thanks for taking the time :-) -%<- [126] [EMAIL PROTECTED]> soffice -env:UNO_JAVA_JFW_JREHOME=file:///usr/lib/jvm/java-1.5.0-sun-1.5.0.06/ -env:UNO_JAVA_JFW_CLASSPATH=/usr/lib/openoffice/program/classes/jurt.jar;/usr/lib/openoffice/program/classes/ridl.jar;/usr/lib/openoffice/program/classes/java_uno.jar;/usr/lib/openoffice/program/classes/juh.jar;/usr/lib/openoffice/program/classes/jut.jar;/usr/lib/openoffice/program/classes/unoidl.jar Xlib: unexpected async reply (sequence 0x1e3a)! -%<- and here the gdb output. Do you need more? (gdb) t 2 [Switching to thread 2 (Thread -1564783696 (LWP 20246))]#0 0xa7235199 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 (gdb) bt #0 0xa7235199 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #1 0xa7231f13 in _L_mutex_lock_148 () from /lib/tls/libpthread.so.0 #2 0xa2baa774 in ?? () #3 0xa76aba2d in typelib_typedescriptionreference_release () from /usr/lib/openoffice/program/libuno_cppu.so.3 #4 0xa750d295 in osl_acquireMutex () from /usr/lib/openoffice/program/libuno_sal.so.3 #5 0xa7739428 in vos::OMutex::acquire () from /usr/lib/openoffice/program/libvos3gcc3.so #6 0xa418c2d9 in SalYieldMutex::acquire () from /usr/lib/openoffice/program/libvclplug_gen680li.so #7 0xa3db4eee in framework::LockHelper::acquire () from /usr/lib/openoffice/program/libfwi680li.so #8 0xa2e5c3f6 in ?? () from /usr/lib/openoffice/program/libfwk680li.so #9 0xa2e5c415 in ?? () from /usr/lib/openoffice/program/libfwk680li.so #10 0xa2e88d59 in component_writeInfo () from /usr/lib/openoffice/program/libfwk680li.so #11 0xa0ad8d72 in GetModuleFieldUnit () from /usr/lib/openoffice/program/libsvx680li.so #12 0xa0adb590 in GetModuleFieldUnit () from /usr/lib/openoffice/program/libsvx680li.so #13 0xa0ad9c48 in GetModuleFieldUnit () from /usr/lib/openoffice/program/libsvx680li.so ---Type to continue, or q to quit--- #14 0xa0bf3cdd in SvxUnoDashTable_createInstance () from /usr/lib/openoffice/program/libsvx680li.so #15 0xa0bf4431 in SvxUnoDashTable_createInstance () from /usr/lib/openoffice/program/libsvx680li.so #16 0x08069ca5 in desktop::impl_callRecoveryUI () #17 0x0806ab5c in desktop::Desktop::SaveTasks () #18 0x0806b07e in desktop::Desktop::Exception () #19 0xa7d8e906 in DeInitVCL () from /usr/lib/openoffice/program/libvcl680li.so #20 0xa7740927 in vos::_cpp_OSignalHandler_Function () from /usr/lib/openoffice/program/libvos3gcc3.so #21 0xa7740944 in _OSignalHandler_Function () from /usr/lib/openoffice/program/libvos3gcc3.so #22 0xa75145c3 in osl_getVolumeInformation () from /usr/lib/openoffice/program/libuno_sal.so.3 #23 0xa7514901 in osl_setErrorReporting () from /usr/lib/openoffice/program/libuno_sal.so.3 #24 0x0017 in ?? () #25 0x081576f0 in ?? () #26 0x0001 in ?? () #27 0x in ?? () This is interesting, it seems that somehow an asynchronous signal has arrived, trying to acquire the Solar Mutex before saving all tasks/documents and terminating the office ... This is not an asynchronous signal only ... it's our crash handling. That means: one of these threads produced a crash and here we try to save all currently open documents. So the deadlock is a follow up of a crash in a remote use case of the office. Solutions: a) Fix the reason for the crash .-) b) Disable Recovery in your use case by using the command line parameter "-norestore" by starting the office. (gdb) t 1 [Switching to thread 1 (Thread -1508009760 (LWP 20207))]#0 0xa6fdc819 in poll () from /lib/tls/libc.so.6 (gdb) bt #0 0xa6fdc819 in poll () from /lib/tls/libc.so.6 #1 0xa728e7f3 in _XEnq () from /usr/lib/libX11.so.6 #2 0xa728ec69 in _XRead () from /usr/lib/libX11.so.6 #3 0xa728fcd5 in _XReply () from /usr/lib/libX11.so.6 #4 0xa7271845 in _XGetWindowAttributes () from /usr/lib/libX11.so.6 #5 0xa72719c2 in XGetWindowAttributes () from /usr/lib/libX11.so.6 #6 0xa4168478 in X11SalGraphics::getBitmap () from /usr/lib/openoffice/program/libvclplug_gen680li.so #7 0xa7e55ff7 in SalGraphics::GetBitmap () from /usr/lib/openoffice/program/libvcl680li.so #8 0xa7df3861 in OutputDevice::GetBitmap () from /usr/lib/openoffice/program/libvcl680li.so #9 0xa7df5650 in OutputDevice::DrawImage () from /usr/lib/openoffice/program/libvcl680li.so #10 0xa7df6a25 in OutputDevice::DrawImage () from /usr/lib/openoffice/program/libvcl680li.so #11 0xa7df6df8 in OutputDevice::DrawBitmapEx () from /usr/lib/openoffice/program/libvcl680li.so #12 0xa7dceea0 in GraphicReader::~GraphicReader () from /usr/lib/openoffice/program/libvcl680li.so #13 0xa7df52ff in OutputDevice::DrawImage () from /usr/lib/openoffice/program/libvcl680li.so #14 0xa7eb986b in ToolBox::Docking () ---Type to continue, or q to quit--
Re: [api-dev] Regarding XJobExecutor.
bharathy b wrote:
Hi i wanted to know if the following is possible using the XJobExecutor.
Is it possible to have more than one trigger method for an XJobExecutor?
At present i have added a toolbar button to the writer document using an Addon. (Using an UNO Component in Java).
Onclick of the button creates an htm file in C drive.
But now i need to add more buttons to the writer document using a Addon. Suppose i want to add 3 buttons using a single addon. how can i specify the trigger method for the remaining 2 buttons.
If you implement an XJobExecutor you use an URL like
"service:". You can use "service:?argument".
In such case your implementation will be called within
"trigger('argument')".
Some examples:
Button 1 URL = "service:YourService?button1" => trigger('button1')
Button 2 URL = "service:YourService?button2?somethingspecial" =>
trigger('button2?somethingspecial')
You will get the whole string from the first "?" till the end as one
string argument. Parsing these string value is up to your code.
Are there any better ways of doing this?
I tried using ProtocolHandlerAddon but i am still not able to understand
dispatcher implementation and how to get the Add-on register itself for the
protocol part of the command URL.
Implementing a ProtocolHandler is the better way ...
Because you can specify your own URL schema as e.g.
"vnd.your_url:/param1?arg1=value1".
Further a ProtocolHandler will be initialized with the right
environment. It will get the current frame/controller/model so it can
start working directly, without the need fort searching those resources.
Please reply and suggest me how to accomplish this..
With Regards,
Bharathy B
-
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Regarding XJobExecutor.
bharathy b wrote:
Hi Andreas thank you, i tried the solution you specified.
In the Addons.xcu i made the following changes.
service:name.vojta.openoffice.wavelet.Wavelet?button1
service:name.vojta.openoffice.wavelet.Wavelet?button2
and in Wavelet.java i made the following change
public void trigger(String buttonName)
{
try{
if (buttonName == "button1")
{
URL yahoo = new URL("http://www.yahoo.com/";);
BufferedReader in = new BufferedReader(
new InputStreamReader(
yahoo.openStream()));
String inputLine;
File outFile = new File("c:\\button1.htm");
FileWriter out = new FileWriter(outFile);
while ((inputLine = in.readLine()) != null)
{
out.write(inputLine);
}
in.close();
out.close();
}
else
if (buttonName == "button2")
{
URL google = new URL("http://www.google.com/";);
BufferedReader in = new BufferedReader(
new InputStreamReader(
google.openStream()));
String inputLine;
File outFile = new File("c:\\button2.htm");
FileWriter out = new FileWriter(outFile);
while ((inputLine = in.readLine()) != null)
{
out.write(inputLine);
}
in.close();
out.close();
}
}
catch(java.io.IOException e){}
}
The buttons appear but dont get triggered. Whats wrong in this method?
If this method will be called ... nothing was wrong.
If it's not called you may be implement your service wrong.
Then the optional interface XJobExecutor couldnt be queried on your
implementation and isnt used.
Was your methor trigger() called ... even with right or wrong arguments
? If not - please check your service implementation and registration.
Regarding the ProtocolHandlerAddon method..
I want to know where should i define sayHello( ).
public String sayHello() { return "Hello world"
}
This is XTestFunction1.idl in C:\ProtoToolbar\Code\com\sun\star\demo
#include
module com { module sun { module star { module demo {
interface XTestFunction1 : com::sun::star::uno::XInterface {
String sayHello();
};
};};};};
This is TestFunction1.idl in C:\ProtoToolbar\Code\com\sun\star\demo
#include "XTestFunction1.idl"
module com { module sun { module star { module demo {
service TestFunction1
{
interface com::sun::star::demo::XTestFunction1;
};};};};};
C:\ProtoToolbar\Code\com\sun\star\demo also contains TestFunction1.urd, XTestFunction1.urd and demo.rdb
Should i define sayHello( ) in TestFunction1.java or XTestFunction1.java? so that sayHello( ) gets called onclick of the button
Should the value of the URL in the Addons.xcu be
com.sun.star.demo:sayHello
I am not able to understand this one point..
Implementing a ProtocolHandler isnt so different against implementation
of a JobExecutor. All interfaces are still defined and can be used.
But your implementation has to support and implement it.
A Protocolhandler has to implement the existing interfaces:
com.sun.star.frame.XDispatchProvider
com.sun.star.frame.XDispatch
[optional] com.sun.star.lang.XInitialization
With regards,
Bharathy B
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OOo 2.0.3 (Linux & Windows), OOoBean, printing does not work when doc loaded with loadFromByteArray()
Mathias Bauer wrote: Harald Weyhing wrote: Hi all, I still can't print with OOo 2.0.3 using the OOoBean, when documents are loaded via loadFromByteArray(). There is no error message, printing silently fails. A workaround for that is calling storeAsURL(url,null) on the document (which is a com.sun.star.comp.beans.OfficeDocument) before calling print. Is there any way to avoid saving temporary files to be able to print in my scenario? Possibly you have found a bug. Until nobody has found the root cause for it we can't suggest any workarounds or alternatives. Best regards, Mathias The corresponding issue is #65519#. Printing without a valid title isnt possible. Otherwise you cant see your job inside the printer queue of your OS. The fix is on the way into the master. Please stay tuned. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] LoadComponentFromURL using an XInputStream in Basic
Andrew Douglas Pitonyak wrote:
I am using OOo 2.0.3 on Linux FC4.
I store a binary file into a database - Base document if it matters.
First I tried to use a stream:
oStatement.setBinaryStream(2, oStream, oStream.getLength())
The error message said that there was an error from the ODBC driver
stating that the stream was NULL. I found that the following works:
lLen = oStream.getLength()
ReDim oData(0 To lLen-1)
oStream.readBytes(oData(), lLen)
oStatement.setBytes(2, oData(), lLen)
I can extract the data from my database to a file.
oSimpleFileAccess.writeFile(sURL, oStream)
Rather than writing the file to disk, I would prefer to load the file
directly.
Dim oProp(0) As New com.sun.star.beans.PropertyValue
oProp(0).Name = "InputStream" : oProp(0).Value = oStream
REM oProp(1).Name = "ReadOnly": oProp(1).Value = True
REM oProp(2).Name = "FilterName" : oProp(2).Value = "writer8"
StarDesktop.LoadComponentFromUrl("private:stream", "_blank", 0, oProp())
When I try this, however, soffice locks up and I have to manually kill
soffice.
The closest that I could find to a solution is in Java, but it uses a
com.sun.star.lib.uno.adapter.ByteArrayToXInputStreamAdapter
The speculation is that the XInputStream does not support XSeekable.
http://joott.cvs.sourceforge.net/joott/jooconverter2/src/net/sf/jooreports/openoffice/converter/OpenOfficeDocumentConverter.java?view=markup
An "InputStream" property of the MediaDescriptor has to support
XSeekable also. Otherwhise OOo cant deal with it.
But normaly that shouldn't produce a "locked" office instance.
The load request should fail.
But a locked office can be produced by the content you try to load.
Might be the used filter does not match to the type of content you wish
to load. You said that you tried to load a Base document ... but you use
a writer filter ("writer8"). That can produce trouble.
Solutions:
a) Let your stream provide the interface XSeekable.
b) Use another filter or dont specify any filter so
loadComponentFromURL() can search for it's own one.
c) Try to load several other contents, to make sure that your problem is
not related to these.
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] how to dispatch ".uno:ClosePreview" from java ?
Oliver Brinzing wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
at the moment I am trying to convert some of my basic macros into a java
component :-)
but get stuck with the following problem:
dispatching ".uno:ClosePreview" from java seems not to work in all cases,
if I open a message box directly after the "xDispatch.executeDispatch" the
message
box will be displayed in the preview mode ... after closing the message box, we
are
still in the preview mode ... the dispatch got lost ???
I think this i caused due to the async behaviour of the dispatching framwork ...
I also tried xNotifyingDispatcher.dispatchWithNotification() without success
... :-(
In Basic I used the following:
Function ClosePreview()
Dim oView as Object
Dim oDispatcher as Object
Dim mNoArgs()
Dim i as Integer
oView = ThisComponent.getCurrentController()
If Not hasUnoInterfaces(oView, "com.sun.star.sheet.XSpreadsheetView")
Then
oDispatcher =
createUnoService("com.sun.star.frame.DispatchHelper")
oDispatcher.executeDispatch(ThisComponent.getCurrentController().Frame,
".uno:ClosePreview", "",
0, mNoArgs())
While Not hasUnoInterfaces(oView,
"com.sun.star.sheet.XSpreadsheetView") and i < 10
Wait(0)
oView = ThisComponent.getCurrentController()
i = i + 1
Wend
EndIf
MsgBox "Hello World..." & CStr(i)
End Function
Any hints ?
Using of the interface XNotifyingDispatch does not make the dispatch
itself synchron ... it guarantees only, that the given listener will be
called. Becausde normal XStatusListener used for a XDispatch call are
not guaranteed to be used !
If you wish to force a synchronous execution of your dispatch you should
try the argument "Asynchron" as [bool] with a valud "false".
But note: Forcing the synchron mode for an asnychronous operation can
make trouble. E.g. closing of such preview will destroy resources, which
are used by your own java code. In such case Disposed- or
RuntimeExcception can occure, which of course must be handled by your
code. You have to make sure that all references to these preview was
released by yourself
/Hint: GarbageCollector .-)
Oliver
- --
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] how to dispatch ".uno:ClosePreview" from java ?
Hello Oliver, If you wish to force a synchronous execution of your dispatch you should try the argument "Asynchron" as [bool] with a valud "false". are you sure, this works ? I can see no difference ... the preview is not closed even if I use xProps[0] = new PropertyValue(); xProps[0].Name = "Asynchron"; xProps[0].Value = Boolean.FALSE; Object oDispatch = xDispatch.executeDispatch(xProvider, ".uno:ClosePreview"l, "", 0, xProps); It's not guaranteed that such parameter will be supported by this dispatch. It depends from it's internal implementation. On the other side I do not know if this dispatch is realy asynchron internaly. It's not a must. BTW: Most of our ".uno:" dispatch implementations support that parameter ... but might be not this special one .-) Dispatches "can be" asynchron or synchron ! The dispatch API should be used in cases only, where a result of an operation is not realy needed. The intention of these API was a smal l binding between a generic UI and the core API (based on URL's) - nothing more. Normaly a menu or toolbar entry has not to deal with the result of such dispatch request ! Next possible solutions: a) close these preview using another API b) use XNotifyingDispatch in combination with a XDispatchResultListener. But note: This interface is an optional one. If the returned dispatch object does not support it ... it's not usable .-) In case these interface will be supported you can provide a listener there. These listener must be called by the dispatch object if the internal operation was finished (normaly that means if the preview was clsoed - even if it was executed asynchronous). But you have to wait for this notification, The return of the dispatch call is not enough ! If b) does not work only a) can solve your problem. Oliver - -- Best Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] LoadComponentFromURL using an XInputStream in Basic
Hello Andrew, Andreas Schlüns wrote: I store a Write document into a Base document. I am storing Binary date in a Base Document, which uses the internal database. I know how to use a macro to open the file, read the file into a byte array and store the document into the database. I also know how to get the data out of the Base document and store it back onto disk using a normal stream. What I want to do, is to extract the Write document from the database (Base) and then open it for editing. I can store the Write document on disk and then load it from disk, but I am trying to skip that step. I obtain a stream as follows: sSQL = "SELECT DATA FROM BINDATA WHERE NAME='" & sFileName & "'" oResult = oStatement.executeQuery(sSQL) If Not IsNull(oResult) Then oResult.next() oStream = oResult.getBinaryStream(1) End If I can not use this stream to open the document because it does not support XSeekable. From Basic, I can obtain an array of bytes, but I do not know how to use that to open the document directly. Solutions: a) Let your stream provide the interface XSeekable. In Java, I can use the com.sun.star.lib.uno.adapter.ByteArrayToXInputStreamAdapter to convert a byte array to an appropriate stream, but this does not appear to be available in Basic. Perhaps this is a problem that can not be solved directly using Basic. It can be solved ... if you implement an UNO Service which accepts a Sequence< sal_Int8 > as IN parameter and returns an XSeekable/XInputStream as result. Such service can be used in Java, C++, Basic, Phyton etcpp. Currently I do not know if such help service still exists .-) b) Use another filter or dont specify any filter so loadComponentFromURL() can search for it's own one. I have tried specifying, and not specifying, the filter. Then it does not depend on your content. It seams realy a problem of your non-seekable stream. But I don not understand then why the office locked up. Normaly the call loadComponentFromURL() should return without loading this content. May be you can provide some stacks (produced with an attached debugger), which shows us, where the office is hanging ? Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] how to dispatch ".uno:ClosePreview" from java ?
Oliver Brinzing wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Andreas, thanks for the detailed explanation ... I always try to avoid using dispatches ... Next possible solutions: a) close these preview using another API but I can not find an api for closing the calc preview ... There exists only an API to close the whole document/frame ... switching from one view to another one can be reached currently only by the dispatch ... if I'm not wrong .-( Did you try the XNotifyingDispatch solution ? If your listener will be called before the operation was realy done, it seams to be a bug. Oliver - -- Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] HoTo disable "Close Document" icon
Harald Weyhing schrieb: Carsten Driesner wrote: Harald Weyhing wrote: Hi everybody, I need to disable or better remove the small "x" like icon on the upper right. I tried to intercept .uno.CloseDoc, but this will only intercepts Ctrl-W, but not when you click the "x". I am using OOo 2.0.3 and OOoBean. Any help would be greatly appreciated. Hi Harald, Unfortunately this is currently not possible. We working on a solution for OOo 2.1, where you could intercept ".uno:CloseFrame". There won't be an option to remove the small "x" on the menu bar. The fix is on the way to an OOo 2.1 version ... but instead of ".uno:CloseFrame" the URL, which has to be intercepted will be ".uno:CloseWin". Regards, Carsten Hi Carsten, thanks for your quick reply, even though this is not good news. Well, Seems that I have to wait for 2.1 then or find some nice workaround. If so, I will post it to the list. There is no workaround available .-) BTW: If you disable the function behind this special closer, + you redefine the whole shutdown scenario of OOo. E.g. closing of the last open office window will shutdown the whole process ... You should know, what you are doing there before you disable this functionality .-)) Cheers Harald Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OnCloseApp not dispatched by OO 2.0.1
Julien Galand schrieb: Hi, I have noticed with an add-on I have written that the global event "OnCloseApp" is not dispatched by OO 2.0.1 (or maybe OO disconnects global event listeners too early when quitting). With the same add-on and OO 2.0.3, this event is correctly received. I have searched in the issue tracker for "OnCloseApp", I haven't found any related issue. Maybe I haven't searched rightly. Is this bug known (if it is one) ? Has it been fixed in OO 2.0.2 or 2.0.3, so that I can warn my customers ? I dont know if this was a known issue on 2.0.1 ... but as you already wrote: it works for versions > 2.0.1. On the other side ... if we find out that it's realy a bug inside 2.0.1 - we cant fix it there .-) Anyway: your customer has to use versions > 2.0.1. Otherwise your add-on doesnt work right. But if customer does not have a problem with 2.0.1 (because they does not detect the problem by herself) why you should unsettle your customers ? Julien Galand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] CloseVetoException vs. TerminateVetoException
Tobias Krais schrieb:
Hi together,
I wrote a little cute java program that is converting documents via OOo.
This conversion machine is running hidden. It will fail, even crash down
if someone uses OOo in foreground and closes the last opened window. For
this reason I registered a TerminateListener that throws a
TerminateVetoException, which prevents my lovely program from crashing.
But this exception even prevents the user to close his visible document(s).
So I search for a better solution and thought a CloseListener throwing a
CloseVetoException could be one. But it works only half. Here is the
code I use:
-%<
public void addCloseListener() {
// initial close listener
xCloseListener = new XCloseListener() {
public void queryClosing(EventObject arg0, boolean arg1)
throws CloseVetoException {
throw new CloseVetoException();
}
public void notifyClosing(EventObject arg0) {}
public void disposing(EventObject arg0) {}
};
this.xComponent.addEventListener(xCloseListener);
}
-%<-
The result is, that I again cannot close the visible OOo Desktop - but I
can close my document!
Is there a solution, to use the CloseListener (or any other Listener)
that allows the user to close the visible OOo desktop, but prevents my
hidden document and OOo to close?
No ... currently not (not realy).
You can listen for closing events on every document opened by YOUR code
and prevent them from closing. Then the desktop should close all
documents not throwing an exception (which should be the UI opened
documents only) and ignore your documents ... which will result into a
failed terminate operation.
But there is a "small time frame", where you cant control the situation
... the time between loadComponentFromURL() returned a document and you
will be registered as close listener. OK - the chance that an UI office
terminates during these 200 ms is very small ... but this possibility
exists .-)
Fact is: the office isnt prepared for such "concurrent uses cases".
There exists two simple uses cases only:
a) UI Office (as normaly used on the desktop
b) API Office (as you use it)
There is another solution for you ...
If you start the office with an own user layer, you will get an own
office instance independed from the normal UI desktop office.
"soffice -env:".
Problem here: all settings made inside the desktop office has to be done
twice. There is no synchronization .-)
Greetings, Tobias
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] CloseVetoException vs. TerminateVetoException
Mathias Bauer schrieb: Hi Andreas, Andreas Schlüns wrote: I wrote a little cute java program that is converting documents via OOo. This conversion machine is running hidden. It will fail, even crash down if someone uses OOo in foreground and closes the last opened window. For this reason I registered a TerminateListener that throws a TerminateVetoException, which prevents my lovely program from crashing. But this exception even prevents the user to close his visible document(s). Is there a solution, to use the CloseListener (or any other Listener) that allows the user to close the visible OOo desktop, but prevents my hidden document and OOo to close? No ... currently not (not realy). Andreas, do you remember what was the reason for the current design decision to prevent the tasks from being closed just because a TerminateListener opted against termination? Yes ... e.g. the QuickStarter wish to disagree with closing of the office ... but not to supress closing of frames. But the (old) Desktop.terminate() API doesnt have an option to differ between these two modes: closing app / closing frames. So the QuickStarter implementation is well known to the desktop (by checking the implementation name of every terminate listener and using the QuickStarter-TerminateListener object explicitly). But this is more a "workaround" then a solution. The problem of Tobias lets me think that the current way of doing things isn't helpful for those who use a termination listener. Or let's put it the other way around: what kind of evil things would/could happen if we first closed all tasks and then called queryTermination() as we do for the Quickstarter? As I said ... the QuickStarter is used differently to all other terminate listener .-) Of course I can change this behaviour ... but we dont know, which "real" terminate listener whish to have the old behaviour. By the way ... there is an example, why terminate shouldnt close any document before asking all registered listener: I know OOo programmer who wrote scripts/addon's, which open several documents at the same time. And they whished to supress closing of this set of documents. But instead of listen for close events on every document/frame ... they decided to listen for terminate events only. So these terminate listener uses the "shortest way" to hinder the office on closing these frames .-) Yes ... that's wrong - but it's public. An yes: there is no guarantee that these frames wont be closed by other objects (other then the desktop). Of course we would be at the mercy of the listener that he will terminate OOo later and so prevent a running OOo instance without any visual elements that allow to close it. But isn't that the idea behind the TerminateListener anyway? I dont like the idea that Desktop.terminate() is used for closing a "visible office" only. Internal it does not differ between hidden and visible documents. Terminate closes it all. Mathias: Do you realy like to open the "Büchse der Pandora" here .-) Ciao, Mathias Ciao Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Enable toolbar items if dynamic protocol handler
Hello Julien, What about my other proposed solution? Use a job and register your service before any UI is visible. I will remember this solution. I have set it aside for the time being, because a job must be registered again in some OO configuration file (typically in the .xcu of a package), and that is precisely the kind of thing we try to avoid. We want to register everything dynamically. They only way to get a notification about the first opened visible document is using of the job mechanism. OK - you can register any UNO listener on the gloabl css.document.GlobalEventBroadcaster instance (such broadcaster provides any notification about loading/storing/changing office documents) ... but how you will trigger your own listener registration ? Hardly coded inside main() ? But there exists a direct binding between the GlobalEventBroadcaster and the job execution. Jobs can be registered for events (e.g. OnStartApp). Of course registration of such jobs can be done using the configuration only. You said (some postings before) you dont install an AddOn .. you wish to patch the office "dynamicly at runtime". How do you do that ? Julien Galand Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] CloseVetoException vs. TerminateVetoException
Hello Mathias,
Andreas Schlüns wrote:
Yes ... that's wrong - but it's public. An yes: there is no guarantee
that these frames wont be closed by other objects (other then the desktop).
As you said: it isn't a good solution anyway as it doesn't help in all
cases and it is not a documented behavior. And it looks painful. Why not
drop it? We can't always refrain from fixing bugs or API usability
issues just because somebody could rely on the wrong behavior.
"... Why not drop it? ..."
Because registration of close listener directly on the frame has a small
timing problem. Calling of loadComponentFromURL("_blank"/"_default")
will might create a new frame and load the component inside. During
loading time the frame cant be closed (because the load environment will
reject such requests) ... but the component must be returned to the
calli. And between returning the component and registering the listener
it will be possible to have a close request on this frame.
Yes - I know: the chance to close such new created frames seams to be
small ... but it exists (and we had similar bugs for our command line
handling already).
So dropping this functionality isnt enough ... We need more changes in
this area.
Mathias: Do you realy like to open the "Büchse der Pandora" here .-)
I think Pandora's box is already open. :-)
But I'm still not sure what is the right behavior. Bug whatever will
come out of this discussion we should document it and we should have two
defined ways to terminate the desktop: one with trying to close all
tasks and one without. At the end it doesn't matter which choice the
current terminate() call will take.
Of course its a question of documentation and definition.
But as I`ve already said - there are some other design problems around
which must be refactored also.
Currently there exists only two solutions:
a) ignore problems regarding multi-used office instances
b) use your own office instance
(with an own user layer ... "soffice -env:*")
Ciao,
Mathias
Ciao
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Jobs
Tabish F. Mufti schrieb: I read in the developer guide Chapter 4 under Jobs: "A central problem of external components in OpenOffice.org is their lifetime control. Every external component must deal with the possibility that the environment will terminate. It is not efficient to implement lifetime strategies in every job, so the job execution environment takes care of this problem. " Can I get any java example related to this ? ??? The job execution service of OOo make this. Why do you wish to know how it works. You wish to implement a job - not to reimplement the existing job execution service - right ? But if you need the source code of the DevelopersGuide examples ... you should have a look here: "http://api.openoffice.org/source/browse/api/odk/examples/DevelopersGuide"; ... AddOn examples here: "http://api.openoffice.org/source/browse/api/odk/examples/DevelopersGuide/Components/Addons"; ... and Jobs here: "http://api.openoffice.org/source/browse/api/odk/examples/DevelopersGuide/Components/Addons/JobsAddon"; Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Jobs
Tabish F. Mufti schrieb: I read in the developer guide Chapter 4 under Jobs: "A central problem of external components in OpenOffice.org is their lifetime control. Every external component must deal with the possibility that the environment will terminate. It is not efficient to implement lifetime strategies in every job, so the job execution environment takes care of this problem. " Can I get any java example related to this ? By the way: if you have a look on the image "4.2: Processing command URLs and the job execution environment" of the DevelopersGuide it should be clear how the job execution service works. It's part of the dispatch queue and prevents frame/desktop service(s) from closing or termination. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Server inside a Protocol Handler
Tabish F. Mufti schrieb: I have an Addon in Java and using the ProtocolHandler scheme I start a Socket Server. Once the protocol handler is executed the server is created inside a Thread and left on the jvm to be executed but I think I lose a reference to this server as the ProtocolHandler will just execute a function and return. Is this behaviour ok or is the server a zombie process now which can exit anytime the garbage collector comes and picks up the server object. ProtocolHandler are designed to be multi-instance UNO components. Means: everytime an URL (where a ProtocolHandler is registered for) is triggered by the UI a new instance of such handler will be created, used and released. There is a special hint inside the DevelopersGuide ... saying: "A protocol handler can be implemented as a singleton, but this poses multithreading difficulties. In a multithreaded environment it is most unlikely that the initial frame context matches every following dispatch request. So you have to be prepared for calls to initialize() by multiple threads for multiple frames. A dispatch object can also be used more then once, but must be bound to the target frame that was specified in the original queryDispatch()call. A change of the frame context can cause trouble if the protocol handler returns itself as a dispatch object. A protocol handler singleton must return new dispatch objects for every request, which has to be initialized with the current context of the protocol handler, and you have to synchronize between initialize() and queryDispatch(). The protocol handler would have to serve as a kind of factory for specialized dispatch objects. You can avoid these problems, if you write your protocol handler as a multi-instance service." If you create a thread and return from the dispatch() nobody inside OOo knows your implementation any longer. Only the Java VM hold your thread alive. So it can happen that the office trys to terminate and your VM will be terminated also (hardly!). Solution: implement an asynchronous job (where the job execution service make sure that OOo doesnt terminate) ... or register a listener inside OOo to be notified in case the frame or the whole office will be closed. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Server inside a Protocol Handler
Hello Tabish, Solution: implement an asynchronous job (where the job execution service make sure that OOo doesnt terminate) ... or register a listener inside OOo to be notified in case the frame or the whole office will be closed. If I use asynchronous job can I reference my Server class and call functions on it from within openoffice ? I you wish to access your "server" everytimes a menu / toolbar item is clicked ... you have to implement your ProtocolHandler / Job as singleton. Means: every UNO service manager createInstance() call will return the same object - the same reference. So every dispatch() request will reach the same service instance. But then you will have the problems as described inside the DevelopersGuide. You has to deal with several initialization calls; several environments. Please look here: "http://api.openoffice.org/docs/DevelopersGuide/Components/Components#1_2_1_11_Singleton"; Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Document title
Paolo Mantovani schrieb: Hi Bernard, Alle 19:37, domenica 12 novembre 2006, Bernard Marcelly ha scritto: Bonjour Paolo There is a solution, using getArgs() from the document. Please note: The property "Title" of the list of arguments of a model isnt better (means more stable) then using the "Title" property of the frame. E.g. database documents (more over her "sub documents" a'la formulars, designs etcpp.) wont support this argument currently (not in every situation). That's why I've started to refactor the whole title feature. As Mathias mentioned: cws[titles01] is your friend. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Server inside a Protocol Handler
Tabish F. Mufti schrieb: You can avoid these problems, if you write your protocol handler as a multi-instance service." So how can I write a multi-instance service ? The difference between multi-instance and one instance service (singleton) will be made on creation time. Every java service must have a statuc function called "__getServiceFactory()". Here you decide, if you return a factory creating new instances of your classes every time ... or if you create one singleton of your service only and return always the same instance. Please read the devlopers guide: "http://api.openoffice.org/docs/DevelopersGuide/Components/Components.xhtml"; especialy chapter 4.5 "Simple Component in Java". I you wish to access your "server" everytimes a menu / toolbar item is clicked ... you have to implement your ProtocolHandler / Job as singleton. I need to access my "server" from the menu/toolbar as well as through the ooimpress slide, it'll probably be some button placed on every slide on which click event I want to contact the server. So would it work for both cases ? Yes; that's possible. You need: a) a singleton UNO service implementing your server b) a multi UNO service as ProtocolHandler What's happen then ? Every times you click into the menu/toolbar a new instance of your ProtocolHandler will be created. These ProtocolHandler internaly will create the server (as UNO service!). But everytimes you will get the same server instance (because it's a singleton). So the ProcotolHandler can work on these server and if the dispatch() call was finished the ProtocolHandler can "die". The server will stay alive (because it's hold alive by UNO and the factory). So you will have 1 Server and N ProtocolHandler. Please note: the server will live for the whole time the office runs. So the server must be informed in case the office will shutdown. The best way is to implement the interface com.sun.star.lang.XComponent on the server. UNO will call it's dispose() method then. So the server knows when the office will die. BUT: You shouldnt make expensive things inside this dispose() call. Because if this call reach you most parts of the office was already released. If you whish to have a "more featured" environment on shutdown you must register your server as listener on the right places. The communication between your ProtocolHandler services and your UNO service implementation can use UNO interfaces only. Two solutions are possible: i) You design zour own set own interfaces and methods using IDL files. ii) You "recylce" existing interfaces of the namespace "com.sun.star" .-) E.g. the XDispatch API seams to be flexible enough to implement every communication between two objects .-)) Hopefully this helps you a little bit. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Problems with User text fields
Cedric Bosdonnat schrieb: Hi Christoph, Oliver, Christoph Neumann a écrit : The property is "MacroExecutionMode": PropertyValue[] DocArgs = new PropertyValue[1]; PropertyValue DocArg = new PropertyValue(); DocArg.Name = "MacroExecutionMode"; DocArg.Value = new Short( com.sun.star.document.MacroExecMode.ALWAYS_EXECUTE_NO_WARN); DocArgs[0] = DocArg; so you can: loadComponentFromURL(DocURL, "MyDoc", "_blank", DocArgs); I'm already using it: the macro first opens a Basic dialog and then changes the value of some User TextFields. The Basic dialog is correctly shown and I can trace the macro. But the ThisComponent.getTextFields() returns no field at all instead of 4 or 5 contained in the document. The basic property "ThisComponent" is'nt a realy stable feature. It referrs to the "current document" ... and that can be the problem here. Do you realy know which of your documents is the "current one" at the time you call "ThisComponent.getTextFields()" ? In general "ThisComponent" should be used only in the following case: (my personal opinion !) a) You have one document containing macros. b) You register these macros to the event "OnLoad", so they are started automaticly. c) Then ThisComponent referrs to THESE document. d) You dont open any other document or do any action, which can set ThisComponent to other currently open documents. E.g. a Frame.ControllerWindow.ToFront(true) (which set the focus to this window) can make trouble. Because the ThisComponent will be changed to the document owned by this frame .-) Why do you spread the code of "one operation" on two documents ? Might be you should make it more explicit. How ? You should know which frames/models are interesting for you and use it explicitly. E.g. the desktop service provides easy access to every open frame. You can iterate over all these frames and search for your and all other interesting models there. Or you cache all opened documents (opened by your basic macro) and forward these references to all the code you trigger ... Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] soffice.bin still alive after closing the applet
Hello joan, Hi everybody, I managed to put openoffice.org into an applet, but sometimes when I close the applet there's this soffice.bin process still alive. Is it normal? Is there a way to clear the memory, kill it, etc. through the api? Yes - that is normal. There wont be an "automatic shutdown" if you script an office via API. You have to terminate it explicitly. Please use the one instance service "com.sun.star.frame.Desktop". It's interface method XDesktop.terminate() will try to terminate the office. "Try" means: modifgied documents will show the well known message box (saving ? yes/no) ... even a quickstarter can hinder these method on doing it's job. But under normal circumstances it will do the same then "File->Exit". Another "kill" without any UI, ignoring modified documents etcpp. does not exists ... excepting "kill -sighup " .-) joan Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Adding a new URL Protocol without wildcards
Tobias Krais schrieb: Hi together, one more question: I already succeeded adding a new URL Protocol with wildcards (CommandURL was ".Judas:"). Now I would like to add a URL Protocol without a wildcard. The CommandURLs should be ".Judas:Saveto" and ".Judas:PrintTrays". Here is the relevant part of my ProtocolHandler.xcu: -%< .Judas:Saveto .Judas:PrintTrays -%< I now added two items to the menu with the two CommandURLs above. Both items are enables, but the CommandURL that is received by the Component is only ".Judas:" Where is the rest gone? How can I define a CommandURL without wildcard? This should work (even it was not thought to work this way). And your protocol handler will be called (if I understand you right). So this indicates that matching of the real URL to the protocol supported by your handler still works fine. I have no idea, why the URL is not complete at the time you will be called. Did you checked the right property of the css.util.URL struct ? It seams that ".Judas:" is the protocol part of the URL. Did you looked on the "Complete" part of the URL ? Please check it. Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] officebean : NoRestore Property and document Recovery
news.gmane.org schrieb:
Hello,
I'm using the OfficeBean in a java project in windows, and I'd like to
disable document recovery after a crash for some documents.
I've tried to use the NoRestore Property, with no success.
If I close the application after loading the document, and then I
terminate soffice.bin, on the next start of openoffice I get the
Recovery window.
Any ideas?
Here's an extract from my code, look down for the complete working code
if you want to test:
PropertyValue[] loadProps = new PropertyValue[1];
loadProps[0] = new PropertyValue();
loadProps[0].Name = "NoRestore";
loadProps[0].Value = new Boolean(Boolean.TRUE);
System.out.println(System.currentTimeMillis() + " - Loading blank
document");
oBean.loadFromURL("private:factory/swriter",loadProps);
String docUrl =
createUNOFileURL("mobyv01\\test\\HP_DX2200_uT_P4_524.doc", oBean);
System.out.println(System.currentTimeMillis() + " - Loading document: "
+ docUrl);
oBean.loadFromURL(docUrl, loadProps);
The property "NoRestore" is unknwon and so not supported by
loadComponentFromURL(). The only way to disable recovery is using
of the command line parameter "-norestore" on starting the office.
But that can be a problem for you. I do not know if the bean provide
a way to influence the start process of an used office instance ...
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Protocol handler and Thread.sleep()
Tobias Krais schrieb:
Hi together again,
I implemented a protocol handler for the CommandURL .Judas:PrintTrays.
The target of this new protocol is to print a document on different
printer trays (page one on tray with letter paper, the others on the
tray with normal paper). After sending the print command via API I added
a PrintJobListener:
-%<-
// Querying for the interface XPrintable on the loaded document
XPrintable xPrintable = (XPrintable)
UnoRuntime.queryInterface(XPrintable.class,
this.xComponent);
// Adding a print job listener
XPrintJobBroadcaster selection = (XPrintJobBroadcaster)
UnoRuntime.queryInterface(XPrintJobBroadcaster.class,
xPrintable);
OOPrintJobListener ooPrintJobListener = new OOPrintJobListener();
ooPrintJobListener.setDebug(debug);
selection.addPrintJobListener(ooPrintJobListener);
// Setting the property "Pages" so that only the desired pages
// will be printed.
PropertyValue[] printOpts = new PropertyValue[1];
printOpts[0] = new PropertyValue();
printOpts[0].Name = "Pages";
printOpts[0].Value = myPages;
try {
xPrintable.print(printOpts);
} catch (IllegalArgumentException e) {}
// Watch print process and continue if done.
// TODO: see OO Bug id 72240; don't print a non-existing page, other-
// wise here is a loop.
while (ooPrintJobListener.getStatus() == null ||
ooPrintJobListener.getStatus() == PrintableState.JOB_STARTED)
{
try {
Thread.sleep(2000);
}
catch (InterruptedException e) {}
}
-%<-
In the line where I wait send the Thread sleeping, I send the whole OO
sleeping and my protocol handler throws an exception. Is this a bug or a
feature?
I solved this problem by creating another thread printing my document.
Then it works. But this other thread won't show my dialog if the print
failes. How can I show the dialog if my print failes from an other thread?
All dispatch objects (and ProtocolHandler are such dispatch objects)
will be called synchronous from the main thread of the office. This is
reasoned by the history of the code of OOo. So you are right: your
sleep() call blocks the whole office.
The only solution is forwarding of all dispatch requests, which arrive
your ProtocolHandler object to a special thread. There you can do
anything you like ... even calling sleep().
Greetings, Tobias
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] officebean : NoRestore Property and document Recovery
Harald Weyhing schrieb:
The property "NoRestore" is unknwon and so not supported by
loadComponentFromURL(). The only way to disable recovery is using
of the command line parameter "-norestore" on starting the office.
But that can be a problem for you. I do not know if the bean provide
a way to influence the start process of an used office instance ...
I use the following property:
System.setProperty("com.sun.star.officebean.Options", "-norestore");
OK - you set the value "-norestore" on another place ..
But are you sure that the bean use this system property
realy within a command line starting the office ?
The only way to disable AutoRecovery currently is "soffice.exe -norestore".
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] officebean : NoRestore Property and document Recovery
Harald Weyhing schrieb:
I use the following property:
System.setProperty("com.sun.star.officebean.Options", "-norestore");
OK - you set the value "-norestore" on another place ..
But are you sure that the bean use this system property
realy within a command line starting the office ?
Yes, here is a code snipp from LocalOfficeConnection.java:
sOption is the variable you are interested in.
OK - seams that OOBean uses this property on starting an office.
An office started with such parameter wont use AutoRecovery and friends
then. But (!) ... what will happen if an office instance already is
running ? Then the bean uses this office (by establishing an UNO
connection) ... and dont start a seond instance. So these office
instance will have a functional AutoRecovery.
Please make sure you will start a new office instance
instead of reusing an existing once.
Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Closing OO after the last document was closed
Mathias Bauer schrieb: Reinhold Merk wrote: Hi again, assuming several documents re opened. To prevent the user close *all* documents at once i can disable the exit menu item. So the user must use the close menu item to close the docs one after the other. After closing the last document an empty application window remains - what i want to avoid. You should use the upper closer, the big one above the smaller one. If you dislike the small closer: IIRC there was a configuration setting to remove it so that closing the last window automatically shuts down OOo. Which configuration setting do you mean ? They only way to hide these "special window closer" is to remove the StartModule entry inside Setup.xcu. Ciao, Mathias Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Closing OO after the last document was closed
Hello Reinhold, Hi again, assuming several documents re opened. To prevent the user close *all* documents at once i can disable the exit menu item. So the user must use the close menu item to close the docs one after the other. After closing the last document an empty application window remains - what i want to avoid. If the user closes the last document window the application will shutdown autoamticly. The special StartModule (you name it empty window) will appear only in case you used the special "second" window closer at the right side of the menu. Everything you have to do is to intercept the URL ".uno:CloseWin" which is triggered by this special control. But note: same URL will be dispatched by using the menu entry "Close Window". To close this window with the last close operation, i used a variable which counts the closed docs (by means of a windowListener). If there is only one doc left, i've tried out to execute xDesktop.terminate(), but this yields in a app.crash ... seems to be the wrong way. Calling desktop terminate() automaticly by closing the last open document window is exactly the functionality implemented by OOo. The only thing you need is to "ignore" the special closer control. (As I said: it's call can be intercepted and ignored by doing nothing.) Is there any other possibility to close the application window, something like XClosable for xComponent? The application must not necessarily terminate, it would be enough, if the window becomes invisible. Regards, Reinhold Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Closing OO after the last document was closed
Mathias Bauer schrieb: OOo 1.0 did exactly what you want: shut down OOo when the last document is closed. If you are interested I can look up the configuration setting you have to set. That would be an interesting alternative! Would be very nice, if you look up. Andreas, do you remember how the start module is disabled? BTW: a side effect of this will be that starting "soffice" will always open a blank new Writer document by default. You have to install an extension containing the following configuration file: (Setup.xcu) http://openoffice.org/2001/registry"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; oor:package="org.openoffice" oor:name="Setup" > The following will happen: a) Starting an office without any parameter will open an empty writer document. b) The "black closer" inside menu will disappear. c) Office will terminate immediatly after closing of last visible document. ... btw: there seams to be a small problem .-) Using menu entry "Window->Close Window" will produce a gray window looking similar to the start module window. But there wont be any menu nor a toolbar available. It's a pure XFrame without any component inside. Issue will follow. Ciao, Mathias Ciao Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Closing OO after the last document was closed
Hello Reinhold , Hi Mathias, Hi Andreas, thanks for your great help! After making some tests, i agree that terminating the office is the wrong way in this case... i haven't taken this 'side effect' into consideration. Now i have to start over. I won't annoy you, but let me once again get back to my initial question: if the last document was closed (via File-Close or the second, smaller window closer), is there any possibility to close the StartModule via the java app, i.e. to simulate a additional File-Close operation to make this window invisible? Once again thanks in advance! If I understand you right you whish to let the office in memory even if the last visible document was closed - right ? Further you are not interested on the special StartModule window - right ? a) You should disbale the StartModule as I've described in one of my previous postings. (setup.xcu) b) You should register a XTerminateListener on the global Desktop service instance. On calling queryTermination() you have to throw an exception ... and as a result of that the office wont terminate. Of course ... you have to decide then when the office will realy terminate. Ciao, Reinhold - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ciao Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Writer: canceling dispose event
Hello Michael, Hi, I have a listener on a Writer document, which gets triggered, when the document gets closed by the user. The file should then be transferred to a database, but it is still locked by OpenOffice. When I try to manually dispose Writer in the event, OpenOffice crashes, which is not a surprise considering that it is already disposing. Can I cancel the disposing or release the file in another way? Does anyone has an idea?? Thanks in advance! It depends from the type of listener you registered ... If you used an css.util.XCloseListener you can hinder the document from being closed by throwing a veto exception in method XCloseListener.queryClosing(). But if you called within method XCloseListener.notifyClosing() it's to late .-) If you registered a normal css.lang.XEventListener its not possible at all. Please note: independed from the type of listener you use ... You shouldnt start closing the document by yourself within those special listener callback. You should accept or reject close requests only - the rest is done by the document itself. Otherwhise it will crash - as you saw it already .-) Regards, Michael Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] problem removing XDispatchProviderInterceptor ...
Hello Oliver, I had a look on your example (because dispatch interception is more my area then Carsten ones). One question ... is the demo you sent the real application or a demo only ? The problem is that your main() method does the following one: a) bootstrap an office b) retrieving the UNO context from the office c) retrieving important UNO services (a'la Desktop, CurrentComponent etcpp) d) register the dispatch interceptor e) disable all macro-commands by returning NULL inside queryDispatch() f) leaving main g) terminating the JVM ! And thats exactly your problem. Nobody hold the client process alive. So you register some UNO listener inside the office, shutdown the JVM and all these listener are dead. Solution: Please make sure your demo application will wait for an event which indicates that all processes are finished. Or better: write an AddOn instead of a client application. Such AddOn is used inside the office process and lives till all UNO-Java objects are gone or the office process will be terminated explicitly. Best Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Interrupt document loading if it takes too long?
Hello Mirko, Hi, I was wondering if there is any way to tell OOo to stop loading a document - i.e. XComponentLoader.loadComponentFromURL() - after starting the operation? I drive OOo from Java/Uno, but some documents can take a very long time to load - see e.g. http://www.openoffice.org/issues/show_bug.cgi?id=78118 and in some applications it would be better to cancel the operation after a timeout and tell the user "sorry, this document is unsupported" rather than make the user wait for several minutes. You are right - it would be nice to have such feature in OOo ... but currently OOo does not have such feature .-) There are already interface supporting canceling of load requests. css.frame.XFrameLoader and css.document.XFilter. So it seams that only XComponentLoader needs some new functionality. But - please dont forget that those cancel request must be supported by the code implementing the interface. If e.g. the filter is blocked by a system call nobody can cancel these request. The only way I can think of is to terminate the OOo process. Anybody has a better idea? Solution a) XDesktop.terminate() wouldnt help. Because it finds the new created frame used for the load request. And those frame hinder the office on termination. So this API call will return "false". Solution b) Kill the office hardly. Then you will trigger the mechanism behind AutoRecovery and CrashSave. Also not an option to be used realy. Seams you need the new interface XComponentLoader2.cancelLoadComponentFromURL() .-) Thanks Mirko Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Interrupt document loading if it takes too long?
Hello Mirko, Hi Andreas, Andreas Schlüns wrote: I was wondering if there is any way to tell OOo to stop loading a document - i.e. XComponentLoader.loadComponentFromURL() - after starting the operation? You are right - it would be nice to have such feature in OOo ... but currently OOo does not have such feature .-) There are already interface supporting canceling of load requests. css.frame.XFrameLoader and css.document.XFilter. So it seams that only XComponentLoader needs some new functionality. Interesting. Maybe there is a way to obtain a frame from the Desktop and then use XFrameLoader to load the document instead of using XComponentLoader then? Of course it is ... But then you will duplicate the whole code behind loadComponentFromURL(). And thats not so easy. You have to create the frame and the window, you have to deal with typedetection, you have to make sure that some resources (e.g. progress/interaction handler) will be created right, you have to set some additional properties automaticly (macro execution mode etcpp) At least we are talking about nearly 2000 lines of code / it's not a joke .. current implementation of loadComponentFromURL() uses ~2000 lines of C++ code .-) The only way I can think of is to terminate the OOo process. Anybody has a better idea? [...] Solution b) Kill the office hardly. Then you will trigger the mechanism behind AutoRecovery and CrashSave. Also not an option to be used realy. What if OOo is started with -norestore and -nocrashreport? Data lost .-) Its your decision. Thanks Mirko Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] executeDispatch from java UNO client
Hello ashok,
you forgot to define the needed set of properties.
Where InsertText should retrieve the text for inserting ?
BTW: Using the dispatch API in combination with ".uno:" URLs
isnt a stable feature. Means the dispatch API itself will be
stable ... but the implementation of such ".uno:" Command
can be changed ... because it's a direct link to the underlying
application core.
The right way to work with a model is using of it's normal UNO API.
Regards
Andreas
Hello there:
I have a Java UNO client application, which connects to an instance of
OOo and sends dispatches using executeDispatch(). Unfortunately
nothing happens, and I dont get an exception or an error message, in
fact everything seems to run smoothly only that nothing happens to the
document (I tried sending simple .uno:StyleApply and .uno:InsertText
dispatches).
What could be the problem? Is it something to do with the Java UNO
client and OOo running as different processes ?
Here is the code for the dispatch :
try {
final XModel docModel = this.getDocumentModel();
XController docController = docModel.getCurrentController();
final XFrame docFrame = docController.getFrame();
XDispatchProvider docDispatchProvider =
ooQueryInterface.XDispatchProvider(docFrame);
final Object oDispatchHelper =
this.getRemoteServiceManager().createInstanceWithContext("com.sun.star.frame.DispatchHelper",
this.m_xComponentContext);
if (oDispatchHelper == null )
log.debug("executeDispatch oDispatchHelper is null!!");
XDispatchHelper xdispatchHelper =
ooQueryInterface.XDispatchHelper(oDispatchHelper);
xdispatchHelper.executeDispatch(docDispatchProvider, cmd, "",
0, oProperties);
} catch (com.sun.star.uno.Exception ex){
log.debug("error in exeucteDispatch "
+ex.getLocalizedMessage(), ex);
}
thanks
Ashok
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hello Tobias & Hal I think I've been told, and likely here, that in 2.0.x, print listeners like this are no longer necessary, but I'm having a bit of a problem searching and finding this comment and what the background is. In 2.0.x, can I print, then close the document without listening for when the print job is done? Can someone confirm this for me? I've been stuck on this problem for about a month (I thought it was other possibilities, and had another couple issues as well) and I'm at a point where I need to solve it and my client is, understandably, anxious about it. Tried it without the print listener and it crashed. Guess it still needs listeners. I wrote a little Java program being able to do the same you want to do. It opens a document, prints it and closes it. Calling the program again prints the next document,... I also ran into troubles without the print listener. Closing the document too fast will crash the print job. A print job listener is good for other reasons, too. I can send you my code if needed. Its an easy thing. But well, its late in Europe and you wont get much help around this time... You do not need realy a print listener to know when printing of the document will be finished and you can close the document. The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter "Wait=true". see css.view.PrintOptions for further details. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with "false" does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) Greetings, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Urgent!)
Hello Hal, The real problem you have ... printing is by default an asynchronous operation. And of course - if you try to dispose a document which is currently in printing state it can crash (at least it shouldnt ... but it can). The best solution: start the printing job with a well documented parameter "Wait=true". see css.view.PrintOptions for further details. So I can set a print option of "Wait" to "true" and my program will wait until the document is printed? Do I understand that properly? That would simplify several questions I've had along the way. It makes your XPrintable.print() call synchron ! If your call returns the document was printed (at least the content was transfered completely to the underlying print queue of your system). That means you can close the document afterwards without any problems and you can shutdown the whole office without any problems. On the other side it can be important how do you close the document. Do you use dispose() or close(). Documentation say you have to preferr XClosable.close(). That's what I'm using. OK. ... with close(true) I hope :-) Further its always a good idea to control the lifetime of a document without any exception and call close(false). Means - please do not deliver the ownership to the document itself. It can work for a while ... but if you close the application it can make trouble. Because all documents not finished within her jobs ... but closed with "false" does not know how they should handle these situation right. They can of course handle it right ... but mostly they dont do it :-) But if I use "Wait=true" for printing, then close immediately after the doc has been printed, and only load in one at a time, then that should eliminate any problems, right? Yes - and your code will be more readable and easy. There is no need to use polling code, sleeps, threads or listener. Only 3 lines of code are needed ... loadComponentFromURL() print() close() ... OK - excepting some further stuff to define all needed parameters :-) Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Solved?)
Hello Hal Vaughan, Oh, and I am using XCloseable.close(true) to close a document. mmm ... in my last mail I've mentioned to use close(false) .-) It's always better to errors on closing documents by yourself instead of delivering the owner ship to any other and ignore errors here. Lates on closing the whole application you will find such "not realy closed documents" and will run into trouble. 1) Is there a problem with OOo using a dual CPU system with version 2.0.2? Is there a problem with the Java interface using a dual CPU system in the same version? "Multi CPU systems" have a different timing then single CPU machines. Thats a fact. So you will be able to find bugs inside OOo which will might be never occure on a single CPU system. On the other side OOo has some problems with threading. Most times deadlocks occure ... but sometimes also crashes reasoned by non synchronized code sections will occure. That does not mean "you cant use OOo on multi CPU machines". That means only - the chance to find bugs in OOo will be a little bit higher then on single CPU machines :-) 2) How can I keep the Document Recovery Window from popping up and get Java to throw an error instead? You can disable the whole recovery stuff be passing an option "-norecovery" to your command line if you start the office. 3) Is there any other way to find out what problem is causing the Document Recovery issue? Yes - dont cancel recovery and have look on the last dialog. There you will find button which show you the stacktrace. Another idea: attach a debugger to the running office and let your operation run till it crashes. The debugger will show you all threads and stacks. On windows you can use the free Microsoft Visual C++ Express 2005 edition. But note: A debugger will also change the timing so it can happen that the problem does not occure then :-) Best Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Solved?)
Hello Hal , 2) How can I keep the Document Recovery Window from popping up and get Java to throw an error instead? You can disable the whole recovery stuff be passing an option "-norecovery" to your command line if you start the office. Okay. What happens then? Does it throw an error instead? Do I get any notice? Is there a way to disable recovery form within Java? I've had a few issues with running from the command line and using multiple arguments. (Long story on that...) You will get an exception from the bridge you used to connect the office. But those exception can tell you "office has died" only. Nothing more in detail. I know that our boostrap class isnt ready for passing any command line parameter to the office currently. Hopefully that will be changed asap. But sorry - currently the command line way is the only one how recovery can be disabled. mmm ... in the moment I'm thinking about that I had an idea. Might be I can establish a configuration entry which disables recovery at all. On the other side such configuration entry will have some other disadvantages ! If you client application uses the normal user layer of the installed office it will also disable recovery for the UI use case - which might was not expected. Only solution here - use a different configuration layer ... which requires another command line parameter too :-) In one trail, I got the recovery window, closed it, and let my program continue. It then tried to close the document and I got an error because the document had already been disposed of. If I stop the recovery window, it'd be nice to have some other error thrown so I don't find out there's a problem until I try to close it. Hint: you should write your code for closing resources of OOo more gracefully. If you e.g. whish to dispose() a component ... you should catch any css.lang.DisposedException. It doesnt matter if you or some others has destroyed those resource. Same for XCloseable. If you get a DisposedException on close(false) it does not mean a real error ! If there were a way to catch an error or know a document had been lost, that would be a HUGE help and, as long as the document is lost *after* printing, I could program around it. As long as you hold a reference to these document it wont be "lost". But yes - it can be already marked as "disposed". So you have to handle that. 3) Is there any other way to find out what problem is causing the Document Recovery issue? Yes - dont cancel recovery and have look on the last dialog. There you will find button which show you the stacktrace. Another idea: attach a debugger to the running office and let your operation run till it crashes. The debugger will show you all threads and stacks. On windows you can use the free Microsoft Visual C++ Express 2005 edition. I don't have access to Windows development tools. The other issue is that I'm self taught. I've never used any kind of debugger other than print statements. Then you should have a look on the stacktrace shown by the recover dialog as I've mentioned. But note: A debugger will also change the timing so it can happen that the problem does not occure then :-) That's a consideration. Right now my client is quite happy printing to the other printer, but I still want to figure out what is going on here so I can solve it and don't have the same problem again with other clients. I'm going to have to space out my use of her computer for debugging for a while because she's had to give up a lot of time on it for me to debug everything. I will be looking at what I can do along the way and hope that I don't have to ask for time on her system until I have a clear idea of what I can do and have the code completely done. Without a debugger it will be difficult to find such type of problems. Analyzing Java stacktraces of your client application wont help - because they show the request started by your code only. But they cant show you the stacktrace of the remote process (means OOo). Our recovery feature can show you the stack which crashed ... but it doesnt show you all threads. But exactly that can help on analyzing synchronization problems. So the one and only solution to find such problems ... will be a debugger :-) Hal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards NAdreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Print Listeners in OOo 2.0.2 (Solved?)
Hello Hal, Here's the weird part: On this client's computer, when I get the recovery window, OOo is STILL running and if I close that window, my program can still connect to OOo. You must differ between the "crash save" and the "recover files" dialog. First one is shown directly after the crash occured and try to save all currently open documents. After saving of those documents was done the whole office process will be restarted ... and then you will see the "recover files" dialog. To make such reboot possible we use a second process. If you have a look on your task manager you will see two processes (soffice.bin and soffice.exe). Soffice.bin is the "real" office process ... soffice.exe is a small wrapper executable only. The wrapper executable will never crash [hopefully :-)] and so it will stay alive for the whole time. But soffice.bin can crash and will be restartet automaticly by the wrapper. So for an outside user it looks like the office stays alive. On the other side your bridge connection was established directly to the soffice.bin process ... so it should be killed by such reboot also. I do not know anything about smoothless reconnecting such bridges. So I'm wondering how it should work. Are you realy sure that your bridge stays alive ? If I even got just, "OOo is dead," I can deal with that by restarting it. If I could get, "Print successful" from the print function call, I could use that and an "OOo is dead" to know if the doc printed before death. "OOo is dead" should be signaled by a suitable RuntimeException of the bridge thrown by every remote request on any UNO object your client knows. "Print successfully" can be detected if your synchron print call does not throw an exception and you reach your next line of code. Of course real notification of successfully print jobs are done by using a print listener :-) Do you mean a registry entry as in a Windows registry, or in an OOo config file? If it's in a config file, I could make the change when I start and change it back when I'm done, or find another work around. I mean "an OOo config file" of course - otherwise I have to make my code system dependend (linux, windows etcpp) which wont be an option anyway :-) But making such changes at runtime isnt a realy good idea ... Because you must make sure that your client application enever crashes without reseting those option ! Everytime such requests about client-office-scripting use cases occure I have the same tip: configure a special user configuration layer for that use case (different from the normal one). That will make persistent changes possible. You can configur that office instance as you like - you wont need bootstrap code to make all those changes at runtime. See it as a seperate application - different to the normal UI case of OOo. And in fact - its a different application with it's own definitions and settings. From what you're saying, though, the problem is that the recovery flag is not something that can be changed in a running instance. It has to be set as on or off when the program is run. Is that right? Right. It cant be done another way ... otherwise it can happen that a crash occure on starting the office before the configuration setting was realy read from the configuration. Do you know "Münchausen" ? :-) One thing I like about working for myself is that my boss would rather me take longer on a program and produce elegant code than to rush and have something ugly that's hard to maintain. ;-) Best decision you boss ever had :-) Hal Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Document reflow and updating the ToC
Hello Sander,
Hello,
I am using OOo in headless mode together with PyODConverter
(http://www.artofsolving.com/node/26). I made a little change to the
script so it will update the Table of Contents before outputting the
resulting document:
document = self.desktop.loadComponentFromURL(inputUrl, "_blank", 0,
_unoProps(Hidden=True, ReadOnly=True)
try:
indexes = document.getDocumentIndexes()
for i in range(0, indexes.getCount()):
index = indexes.getByIndex(i)
index.update()
except:
pass
document.storeToURL(outputUrl, _unoProps(FilterName=filterName))
However, the indexes aren't updated correctly. I.e. some entries in the
ToC point to the wrong page number.
It seems OOo needs some time to figure out how many pages are in the
document and what title is on what page. I see the same when I open my
document in OOo. When I open my document, it starts out saying that
there are 10 pages, a second later it's 11 and another second later 12.
It seems to be "reflowing" the document several times before everything
is layed out correctly (to borrow that term from web browsers).
If I delete the layout-cache file from the ODF container (and it's entry
in manifest.xml) then it starts out at a pagecount of 18 and reduces
back to 12.
if I add a 10 second sleep between opening the document and updating the
ToC, it does work correctly. But I don't want to add an arbitrary pause
in the document conversion.
Is there a way to force a reflow through the Python Uno API? Or is there
a way to get notified when OOo has finished reflowing and laying out the
document, so I can wait for it?
Sorry - but the answer is "no". The asynchronous layout of our
applications is an optimization to perform loading documents.
In an UI use case you will see the document asap ... and layout will
come later. But you are right ... loadComponentFromURL () is a
synchronous API (btw: the office itself uses the corresponding
dispatch() for loading documents) .. and so the document should be ready
after this method returns - but it isnt.
I will try to find a solution. Please file an issue on OOo and send it
to me ("[EMAIL PROTECTED]"). There exists two ideas:
a) loadComponentFromURL () make sure that layouting was done (my favorit)
b) a special event (send by the GlobalEventBroadcaster) will notify
finishing the asynchronous layout operation.
Kind regards,
Best Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Consume event OnPrepareUnload
Hello Robert, Hallo, is there a way how to consume event receieved from document's XEventListenrr? I can listen for events, but I have no idea how to consume them. The goal is simple - when I have non-modal JFrame opened, I would like to remove possibility to close document until my JFrame disappears. Seams that XEventListener and OnPrepareUnload isnt right doing your job. Such document events are thought to be used for jobs based on the document itself. E.g. changing it's content at runtime depending from external stuff ... or doing something in parallel. Hindering a document on closing has to be done by using the interface XClosable provided by the model (use queryInterface() to retrieve it) and registere a XCloseListener. Such listener will be called also if the document should be closed and it can disagree with that by throwing a suitable CloseVetoException. Note: if such exception was thrown one times might be the source of this exception has to make sure the document will be closed later. Read the interface description carefully. Best regards, Robert Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OO 2.4rc1 disposing(EventObject) on XTerminationListener
Hello Cornelis, Hi, When I connect to OpenOffice.org 2.4 RC1, with the Java UNO bridge (Bootstrap.bootstrap()), I can get the XDesktop and store it in a variable. Now, I add a XTerminateListener to the desktop. After that, I call XDesktop.terminate(). This returns true. At the termination listener I see that queryTermination and notifyTermination is called. So far so good. Openoffice is really closed now, I do not see a process any more. But the disposing(EventObject) is not called. In OpenOffice.org 2.3 and lower, the disposing is called just before OpenOffice dies. Is this a new behaviour or is this a bug? The Desktop service is a special one ... it's designed and implemented as a singleton instance. And those singeltons are disposed by the context service manager directly. Might be here is the reason for the new behaviour. Whats happen on shutdown ? XDesktop.terminate() -> calls XTerminateListener.queryTermination () -> calls XTerminateListener.notifyTermination () -> signals shutdown to process (asynchron !) <- returns result (migtht be TRUE) ... async shutdown will be initiated -> UNO deinitialize -> ServiceManager.dispose() -> XDesktop.dispose() -> XEventListener.dispose() ... bridge already closed ? Now is the question: Can UNO report those notifications over bridges even if it stands in its own deinitialization request ? Might be deinitialization of UNO was changed last time ? Stephan ... seams you know more about those details ? Kind regards, Cornelis Hoeflake Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] OO 2.4rc1 disposing(EventObject) on XTerminationListener
Hello Cornelis,
Hello Andreas,
We need to restart the office from our code, but the process will
deadlock when we bootstrap while another office process is terminating.
So we need a reliable way to determine wether the office is terminated.
By the disposing call, we could know that. Is there another way to
detect that?
If you call for example XDesktop.getCurrentFrame() just after you have
terminated it, the OpenOffice process and the Java process will hang.
The following workaround seems to work, but is dirty:
if (desktop.terminate()) {
while (true) {
try {
context.getServiceManager();
} catch (DisposedException e) {
break;
}
}
} else {
// could not terminate
}
Stephan already accepted that the missing disposing() event is a bug.
On the other side even the disposing() event of XDesktop isnt a real
indicator that new office processes can be started. Those function is
missing at the moment. From my point of view those events (office
context started/terminated) must be provided by the bridge you are
using. But it might be impossible to do so ... because the UNO Service
Manager and it's context are one part of the office only. So there
exists other parts which do not synchronize her doing with the UNO
service manager.
I do not know if, how and when we can solve that issue realy.
But might be there exists a workaround ...
Because it's even not a good idea to start the office in the same way
then it's started as UI office on the desktop you should use one "user
layer" for every instance you start. Exactly those "user layer" (which
resists in you home folder) makes the trouble you found out if two
office processes are started.
Idea:
a) Use a special prepared user layer as template.
b) Copy those layer to a temp location on disc.
c) Start every new office with a parameter
"-env:UserInstallation=file:///"
d) Delete those layer after the office was terminated.
That will make it possible to create a pool of running office instances
for several purposes without the need to synchronize it.
Regards,
Cornelis
Best Regards
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Can I use XDispatchProviderInterceptor in an extension?
Hi Giuseppe, with the Job component implemented and configured it seems to work, thanks. In the meantime, reading the documentation I found this sentence in the DevGuide [1], at the beginning: " ... If both are available, the synchronous service AsyncJob is preferred by the job execution environment. " The words "synchronous service" and "AsyncJob" seem a little out of 'sync' here. Not sure which of the job possible type takes precedence over the other. I'll use a XJob interface only, so I don't need that deep understanding, but that sentence needs to be corrected, I think. Unfortunately I don't know which way to correct it... Or may be it's just me not understanding :-). Seams to be a simple typo ... The sentence should be: "If both are available, the synchronous interface is preferred by the job execution environment." On the implementation side it's more easy than you think :-) For you there exists two possibilities to implement a job: a) the synchronous way using XJob or b) the asynchronous way using XAsynchronousJob. It depends from our use cases which interface should be used/implemented and supported by your job implementation. Sometimes it happened that a programmer decided to support BOTH interfaces at the same implementation. Dont ask me why ? :-) So I've decided to implement a mechanism which preferres one interface in such case - and thats the synchronous interface XJob. Best Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] About XDispatchProviderInterceptor and XFrameActionListener:frameAction()
Hello Giuseppe, Hi all, I implemented an XDispatchProviderInterceptor (as a Java object not a UNO one) it's instantiated when a XJob (synchronous job) is fired by an OnViewCreated event. The interceptor works correctly and and it unregisters as frame event listener and as interceptor when it receives com.sun.star.frame.FrameAction.COMPONENT_DETACHING_value in its frameAction() method. I'm worried about what would happen when another interceptor register itself at the same frame. On the DevGuide I haven't find anything useful. Are there other frame events that need to be detected? The developers guide mention to register one interceptor for one URL only. Ambigous registrations will result in ambigous reactions :-) Of course it can happen that different extensions wish to intercept the same functionality (e.g. .uno:Save) .. but then the last registered interceptor wins the race. A better solution cant exists. Even if any already registered interceptor will be informed about the new interceptor ... what should be done then ? If every "old" interceptor try to register itself again ... its also undefined which one will win the race :-) So I think extensions should define her own URL namespace and bring new functionality to OOo ... not redefining existing functionality. The interceptor mechanism should be used for well known office installations (e.g company installations) not for generic and widely used extensions. TIA Best Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Getting the document name displayed in the title bar of the window
Hello Stefan, Hi, a year ago Matthias B. helped me out, by pointing me to ThisComponent.CurrentController.Frame.Title Unfortunately things have changed in OOo 3.0, so that the title of the frame is no longer equal to the name of an unsaved document, that OOo would pass to the printer driver as the name of the printing job. See also http://www.openoffice.org/issues/show_bug.cgi?id=95320 Can anyone help me out again? I need to retrieve the name OOo 3.0 would deliver to the printer driver as the name of the document to print, using OOo Basic. Thanks for any help! Stefan There is a complete new title API available providing different possibilities a) You can get the title of the document directly from the model. Query a model to its XTitle interface and call getTitle() there. You will get e.g. "Untitled 1" or "". Those title are given without (!) any extra informations like "StarOffice" or "Writer" ! b) Same interface is provided by controller and frame. And every of those objects provides the title of the underlying object plas addtitional informations. E.g. model_title ="Untitled 1" controller_title="Untitled 1:2" (if two views exists) frame_title ="Untitled 1:2 StarOffice Writer ..." OK - now you should be able to get your favorit title ... but it wont help you regarding the printer queue problem you have ! Why ? Because it's a title and not any unique document ID used for any purpose. So it seems that printer API and title API uses the same values ... but at least they dont do that in real. So e.g. the title API does not show you the difference between two documents using the same name but different directories. "dir_1/file_1" and "dir_2/file_1" will have the same title "file_1". I do not know how the printer API deal with that. But for a simple UI title it's not interesting. On the other side the printer API of OOo does not provide any operation regarding the printer queue. So currently I do not see any chance to match document titles against items of a system wide printer queue. One last question ... Can you describe more in detail what are you doing ? Might be there exists another (might be more elegant) solution. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re: Intercepting commands ".uno.xxx..."
Hi Carlos, (I'm using Automation Bridge to communicate with OOo) After reading again all the stuff and trying to digest the java sample, this is what I conluded: I need to implement my own "DispatchProvider" as a COM object an pass it as a parameter to "registerDispatchProviderInterceptor", in the same way I do to register listeners, am I right? (is this the reason why Ariel said this can't be achieved with Basic?) Exactly. You "register" your interception in the same you register a listener. registerDispatchProviderInterceptor() is the right method doing that. And yes ... OOo basic do not support complex structures as e.g. classes and so it's not possible to implement an interceptor in basic. Then (e.g. using VB) I must define the dispatch() method to be called by OOo and react accordingly to the URL - let's say, if I want to handle ".uno:SaveAs" myself I must return null, or else I must return...what? If you call registerDispatchProviderInterceptor() the framework will call setMasterDispatchProvider() and setSlaveDispatchProvider(). Do nothing there excepting caching those two dispatch objects. From this point your interceptor is part of the double-linked interceptor chain. Note: NULL will be a valid parameter for those master/slave dispatch objects provided to you. Such null value will happen in case you deregister your interceptor ... and the framework creates a new chain without you ... If you want to handle the request return "this" or any other suitable instance (e.g. a helper object) ... if not forward the request to your slave dispatch ! Master dispatch can be ignored. I've never seen a use case where it was rely needed .-) Sorry, I'm lost - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Where to register MouseClickHandler in an Add-On?
wheelsdong wrote: Hi Carsten, Thank you very much for your advice. I followed the links you provided and tried to run the example, but I failed. My steps are below. I read the chapters on Jobs of the developer guide. Then I tried the example JobsAddon provided by SDK. The path is OpenOffice.org_2.4_SDK\examples\DevelopersGuide\Components\Addons\JobsAddon There are three files in this example: Addons.xcu, AsyncJob.java, Jobs.xcu. I created a simple OpenOffice.org Add-on using the OpenOffice plugin for NetBeans, we call it NewAddon. Then I did the following: 1, copied the configuration code in Addons.xcu of JobsAddon to Addons.xcu of NewAddon. 2, copied the file Jobs.xcu to the project NewAddon 3, extended XAsyncJob interface in NewAddon and copy the code in executeAsync() to the same method in NewAddon. After building successfully, I made a breakpoint in executeAsync() and tried to debug the NewAddon. But executeAsync() was never called. I am afraid I am not using Jobs correctly. Would you please share me some examples or give me more advice? Thank you very much. Did you changed the Jobs.xcu so it uses the right event ? Example Jobs.xcu file uses e.g. "onFirstVisibleTask" where you should use "OnViewCreated" for your special purpose. Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Where to register MouseClickHandler in an Add-On?
Hi wheelsdong, Your jobs.xcu contains a non existing UNO implementation name. If I'm not wrong your class will be "com.example.MyAddon" ... but you registered "com.sun.star.comp.framework.java.services.AsyncJob" inside Jobs.xcu. That cant work ... of course :-) BTW: Your job name is "AsyncJob". You should use something more unambigous ... Because ALL jobs written for OOo will be merged together into ONE single Jobs.xcu file at runtime ... "AsyncJob" only will be not enough. I thgink more then one developer will use it too .-) You should use YOUR namespace here also (e.g. com.yourcompany.addons.MyJob). Regards Andreas Hi Andreas, Thank you very much for your advice. I changed onFirstVisibleTask to OnViewCreated, but when I debug it, the executeAsync() is still never called. I am afraid there is something wrong with the configuration files. The Attachment is a simple TestAddon created using the OO plugin with NetBeans, which only implements the XAsyncJob interface. And I copied the related information from the example AsyncJob provided by the developer guide. If you have time, would you please help review the project? I much appreciate your help. Andreas Schlüns-2 wrote: wheelsdong wrote: Hi Carsten, Thank you very much for your advice. I followed the links you provided and tried to run the example, but I failed. My steps are below. I read the chapters on Jobs of the developer guide. Then I tried the example JobsAddon provided by SDK. The path is OpenOffice.org_2.4_SDK\examples\DevelopersGuide\Components\Addons\JobsAddon There are three files in this example: Addons.xcu, AsyncJob.java, Jobs.xcu. I created a simple OpenOffice.org Add-on using the OpenOffice plugin for NetBeans, we call it NewAddon. Then I did the following: 1, copied the configuration code in Addons.xcu of JobsAddon to Addons.xcu of NewAddon. 2, copied the file Jobs.xcu to the project NewAddon 3, extended XAsyncJob interface in NewAddon and copy the code in executeAsync() to the same method in NewAddon. After building successfully, I made a breakpoint in executeAsync() and tried to debug the NewAddon. But executeAsync() was never called. I am afraid I am not using Jobs correctly. Would you please share me some examples or give me more advice? Thank you very much. Did you changed the Jobs.xcu so it uses the right event ? Example Jobs.xcu file uses e.g. "onFirstVisibleTask" where you should use "OnViewCreated" for your special purpose. Regards Andreas http://www.nabble.com/file/p20318331/MyAddOn.zip MyAddOn.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re: Intercepting commands ".uno.xxx..."
Hi Paolo, Hi, Andreas Schlüns ha scritto: Hi Carlos, (I'm using Automation Bridge to communicate with OOo) After reading again all the stuff and trying to digest the java sample, this is what I conluded: I need to implement my own "DispatchProvider" as a COM object an pass it as a parameter to "registerDispatchProviderInterceptor", in the same way I do to register listeners, am I right? (is this the reason why Ariel said this can't be achieved with Basic?) Exactly. You "register" your interception in the same you register a listener. registerDispatchProviderInterceptor() is the right method doing that. And yes ... OOo basic do not support complex structures as e.g. classes and so it's not possible to implement an interceptor in basic. Why not? You can register your own dispatch-interceptor in Starbasic and you can even define your custom dispatches in order to react to user actions Please find the small example document in attachment. You are right ... it's possible ... but I wouldnt do that ! Why ? a) Method createUnoListener() was not thought to be used that way. If you call it a temp object will be cerated inside memory (using refelection) which maps your basic methods to an simulated UNO API. Its very tricky doing so ... and at least you need more then one instance because it's not possible to simulate more then one interface for the same basic instance. b) On the other side I believe you can run into trouble with lifetime of your basic objects. They are bound to the document ... if it's removed from memory your basic bindings are gone ... but might be the dispatch objects are well known outside. (Not only menus and toolbars are interested on dispatches!) Such reflection-proxy-objects will run into dead bindings ... an idea whats happen then ? - crash ! If you know what are you doing there you can try it ... but at least I think it's one for OOo-API-experts .-) ciao Paolo Mantovani Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Re: Intercepting commands ".uno.xxx..."
Hi Paolo, My example was contained into a document, but it could be run even from a shared library. AFAIK a global variable into a shared library lives for all the ooo session. Perhaps using global vars for referencing basic objects would make things safer? It's not needed to make it a global variable (because it's an implementation detail of OOo Basic how long such variables will be valid ... isnt it ?) But it can help to listen for several further events (e.g. FrameAction.DETACH/ATTACH or Frame.close/Frame.dispose) so an interceptor can be deregistered and dispatch objects can be removed. BTW: Thats always a good idea ... even if an interceptor/dispatch was implemented e.g. in Java ! Of course you're right! The next time I'll add: "PLEASE, DON'T TRY THIS AT HOME!!!" :-) :-) Paolo Mantovani Regards Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] Where to register MouseClickHandler in an Add-On?
Hi wheelsdong,
First you should try to use your job implementation manually to see if
your implementation was registered successfully as valid UNO service
inside services.rdb of OOo.
Please start the Basic IDE and type in the following small macro:
myjob = createUnoService ("com.example.MyAddOn")
msgbox myjob.dbg_supportedInterfaces ()
If it runs without errors it shows you the list of supported UNO
interfaces provided by your MyAddOn implementation. If creation of such
service fails ... you should check if your class name (including
namespace) is the right one and match the configured value !
Further you should check (if creation of your service was successfully)
if XJob or XAsyncJob are listed as supported interfaces. If not please
check your implementation.
btw: Seems there is a further small mistake inside your Jobs.XCU file.
You should try oor:op="fuse" instead of "replace". Replace works for
STILL existing entries only. But I'm sure that your job was never
registered before inside OOo .-)
Replace do not mean(!) "add or replace" ... that's why "fuse" was
introduced later.
... same for other places where you used oor:op="replace" !
Regards
Andreas
Hi Andreas,
Thank you for finding the errors in the configuration files.
I made modifications according to your suggestions. I changed the name of
Job to com.example.MyAddOn.MyJob, and put the proper implementation name of
my project. And registered the event OnViewCreated and onFirstVisibleTask. I
also add vnd.sun.star.job:event=onFirstVisibleTask in the Addons.xcu file.
I wish that the job will be trigged by the event onFirstVisibleTask. But
When I debug the program, the execute() function is not called at all.
I am afraid I am not understanding the Developer Guide correctly. I also
googled for tutorials or sample code, but didn't find any useful resources.
Would you please help review the code? Thank you very much!
Attachment is the project zip file.
The new Job.xcu file is as follows:
http://openoffice.org/2001/registry";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
com.example.MyAddOn
val_1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [api-dev] XComponentLoader.ComponentFromURL throws IllegalArgumentException: URL seems to be an unsupported one.
Hi Albert,
Why do you load the file using "private:stream" instead of using the
original file:///-URL ? Let OOo do that stream stuff internaly. Loading
via stream is supported but detection of pure streams without any hint
about the URL or the mime type will fail very often ... especialy if
ambigous formats like Text/Html or XML will be used :-)
Regards
Andreas
Hi Albert,
your code works fine for me. Of course, I used only a simple odt
document. Perhaps the filter for loading the docx document cannot be
determined. You can add this to the properties for loadComponentFromUrl,
the name of the property is FilterName, the value the name of the filter
you'd like to use.
Regards, Steffen
Albert Law wrote:
Hi,
Me, again. :)
I'm having problems with XComponentLoader.ComponentFromURL where it is
loading from an XinputStream. I'm a bit paranoid and don't
want this to be a reoccurance of bug 75191 (
http://www.openoffice.org/issues/show_bug.cgi?id=75191 ). Can anyone
see what I could
have possibly done wrong in the following code? Thanks!
ps: The ultimate goal is to load from a byte[]. This seemed to be a
good first step.
pps: Nothing is null and the file does exist. In fact, I have
successfully loaded from a URL via "XComponent xComponent =
xComponentLoader.loadComponentFromURL("file:///c:/test.docx",
"_blank", 0, loadProps);" where "loadProps" is empty.
ppps: I'm using the most recent version of everything.
[begin]
XComponentContext xContext = Bootstrap.bootstrap();
XMultiComponentFactory xServiceManager = xContext.getServiceManager();
Object desktop =
xServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop",
xContext);
XComponentLoader xComponentLoader =
(XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class,
desktop);
XSimpleFileAccess xSimpleFileAccess =
(XSimpleFileAccess)UnoRuntime.queryInterface(XSimpleFileAccess.class,
xServiceManager.createInstanceWithContext("com.sun.star.ucb.SimpleFileAccess",
xContext));
XInputStream xInputStream =
xSimpleFileAccess.openFileRead("file:///c:/test.docx");
PropertyValue[] loadProps = new PropertyValue[1];
loadProps[0] = new PropertyValue();
loadProps[0].Name = "InputStream";
loadProps[0].Value = xInputStream;
XComponent xComponent =
xComponentLoader.loadComponentFromURL("private:stream", "_blank", 0,
loadProps);
[end]
leads to (line numbers are off, of course):
com.sun.star.lang.IllegalArgumentException: URL seems to be an
unsupported one.
at
com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:182)
at
com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:148)
at
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:344)
at
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:313)
at
com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:101)
at
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:652)
at
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:154)
at
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:136)
at $Proxy3.loadComponentFromURL(Unknown Source)
at com.snowbound.testOOUno.main(testOOUno.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.star.lib.loader.Loader.main(Loader.java:144)
-
Albert
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] XComponentLoader.ComponentFromURL throws IllegalArgumentException: URL seems to be an unsupported one.
Hi Albert,
The right FilterName is "MS Word 2007 XML".
And no ... you dont have to provide a XComponent.
It should work if you use "private:stream" + FilterName + XInputStream.
On the other side your example code showed me you have a valid URL ...
and I was wondering why you dont used it here .-)
Please note: Loading documents into OOo only by using streams (means
URL=private:stream) wont have the same detection rate then using real
and valid URL's ! As I've already mentioned ... some formats are
ambigous. Providing a stream only wont solve that ambigous state. You
have to provide MORE informations as e.g.
MimeType/Extension/FilterName/TypeName/TargetApplicationName to make
sure things will happen right.
Regards
Andreas
Hi Steffen,
Okay, that's worth a try... . Ya, it didn't work.
Perhaps I'm using the wrong filter name. I've used the
following filter names to no success.
"Microsoft Word 2007 XML"
"writer_MS_Word_2007"
"MOOX"
Did I use the proper one?
-
Albert
-Original Message-
From: steffen.gr...@sun.com [mailto:steffen.gr...@sun.com]
Sent: Friday, January 09, 2009 02:50
To: dev@api.openoffice.org
Subject: Re: [api-dev] XComponentLoader.ComponentFromURL throws
IllegalArgumentException: URL seems to be an unsupported one.
Hi Albert,
your code works fine for me. Of course, I used only a simple odt
document. Perhaps the filter for loading the docx document cannot be
determined. You can add this to the properties for loadComponentFromUrl,
the name of the property is FilterName, the value the name of the filter
you'd like to use.
Regards, Steffen
Albert Law wrote:
Hi,
Me, again. :)
I'm having problems with XComponentLoader.ComponentFromURL where it is loading
from an XinputStream. I'm a bit paranoid and don't
want this to be a reoccurance of bug 75191 (
http://www.openoffice.org/issues/show_bug.cgi?id=75191 ). Can anyone see what I
could
have possibly done wrong in the following code? Thanks!
ps: The ultimate goal is to load from a byte[]. This seemed to be a good first
step.
pps: Nothing is null and the file does exist. In fact, I have successfully loaded
from a URL via "XComponent xComponent =
xComponentLoader.loadComponentFromURL("file:///c:/test.docx", "_blank", 0, loadProps);"
where "loadProps" is empty.
ppps: I'm using the most recent version of everything.
[begin]
XComponentContext xContext = Bootstrap.bootstrap();
XMultiComponentFactory xServiceManager = xContext.getServiceManager();
Object desktop =
xServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop",
xContext);
XComponentLoader xComponentLoader =
(XComponentLoader)UnoRuntime.queryInterface(XComponentLoader.class, desktop);
XSimpleFileAccess xSimpleFileAccess =
(XSimpleFileAccess)UnoRuntime.queryInterface(XSimpleFileAccess.class,
xServiceManager.createInstanceWithContext("com.sun.star.ucb.SimpleFileAccess",
xContext));
XInputStream xInputStream =
xSimpleFileAccess.openFileRead("file:///c:/test.docx");
PropertyValue[] loadProps = new PropertyValue[1];
loadProps[0] = new PropertyValue();
loadProps[0].Name = "InputStream";
loadProps[0].Value = xInputStream;
XComponent xComponent = xComponentLoader.loadComponentFromURL("private:stream",
"_blank", 0, loadProps);
[end]
leads to (line numbers are off, of course):
com.sun.star.lang.IllegalArgumentException: URL seems to be an unsupported one.
at
com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:182)
at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:148)
at
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:344)
at
com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:313)
at
com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:101)
at
com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:652)
at
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:154)
at
com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:136)
at $Proxy3.loadComponentFromURL(Unknown Source)
at com.snowbound.testOOUno.main(testOOUno.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.star.lib.loader.Loader.main(Loader.java:144)
-
Albert
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...
Re: [api-dev] XComponentLoader.ComponentFromURL throws IllegalArgumentException: URL seems to be an unsupported one.
Hi Albert, I've debugged your problem and found out (as I've already mentioned) that some detection services dont work correctly in case pure input stream is provided only .-) An issue was filed by me so you can track if and when it will be fixed. http://www.openoffice.org/issues/show_bug.cgi?id=98023 Regards Andreas Hi Andreas, I tried "MS Word 2007 XML", but that didn't help. So I'm willing to add extra hints. Though I'm a bit confused as to how I would set the MIME type information. How do I do so? And what should it be set to? Thanks. ps: I wish to use "XinputStream"s so that I may load from memory and avoid going to disk. It is a security requirement of the end-product. I would love to load files from URL and save myself the hassle of XInpuStream (and late XOutputStream). :) - Albert - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
