Thanks for your prompt reply.
> Yes. Create the model as a service and either initialize or load it. In
> Basic code:
>
> model = createUNOService("com.sun.star.text.TextDocument")
> model.initNew()
>
> will create a new empty text document.
>
> dim mediadescriptor(n) as new com.sun.star.beans.PropertyValue
> ' fill mediadescriptor
> model = createUNOService("com.sun.star.text.TextDocument")
> model.load( mediadescriptor )
>
> will create and load a document from what you put into the
> mediadescriptor. Of course in this case you don't have a type detection
> and you must either put the filter name into the mediadescriptor or
> manually call the type detection service (not a big deal).
>
I did not get very far with that. I am writing in java and tried this:
com.sun.star.text.XTextDocument xm = (com.sun.star.text.XTextDocument)
queryInterface(com.sun.star.text.XTextDocument.class,
getMultiServiceFactory().createInstanceWithArguments("com.sun.star.text.TextDocument",
args));
//(com.sun.star.text.XTextDocument)queryInterface(com.sun.star.text.XTextDocument.class,
"com.sun.star.text.TextDocument");
xm.attachResource(surl, args);
> Register a CloseListener at the model and veto against closing as long
> as you need the model. Of course then you must keep track of all models
> and close them by yourself when you are done with them.
>
> I must confess that I don't remember if this really works in your case
> (it definitely works in case of closing the frame) but you could try and
> report back. If it doesn't work it's a bug that needs to be fixed.
>
>> Basically I do this because I don't want multiple XFrames open, but
>> still
>> want concurrent editing of multiple documents.
>>
>> I am trying to reduce the overhead of temporarily writing a stream for
>> the
>> XModel I remove from the frame and rereading, parsing etc... the stream
>> again later.
>>
>> Keeping with this, where is the most overhead in the API, i.e. creating
>> the model, or creating the frame and controller and which uses more
>> resources?
>
> The most resources are taken by the model, the frame and controller are
> much smaller for non-trivial documents. At least that's my guestimation.
>
> Best regards,
> Mathias
>
> --
> Mathias Bauer - OpenOffice.org Application Framework Project Lead
> Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
>
> ---------------------------------------------------------------------
> 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]
