switching components in one frame

Hi,

I'm asking myself if it is possible to start implementing
the following
scenario:

A doc is opened in a frame (and window). On a command of the
user the
component attached to the frame is stored elsewhere to keep
the
reference and a second document (component) is loaded into
that frame.
After a task is done by the user the second component get's
saved and
destroyed and the first component is attached to the frame
again.

The goal is to reuse the window presented to the user with
variing
contents.

Will this work or am I asking for trouble regarding attached
listeners,
dispatch or whatelse?

TIA,
Marc


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Marc Santhoff wrote:

> Hi,
> 
> I'm asking myself if it is possible to start
implementing the following
> scenario:
> 
> A doc is opened in a frame (and window). On a command
of the user the
> component attached to the frame is stored elsewhere to
keep the
> reference and a second document (component) is loaded
into that frame.
> After a task is done by the user the second component
get's saved and
> destroyed and the first component is attached to the
frame again.
> 
> The goal is to reuse the window presented to the user
with variing
> contents.
> 
> Will this work or am I asking for trouble regarding
attached listeners,
> dispatch or whatelse?

A "component" inside a frame comprises a
controller and a model. You can
not keep the controller without the frame, but you can keep
the model
and you can use this model later on to recreate a controller
including a
view from it without reloading the document.

To preserve the model from being closed when its last
controller gets
destroyed you must register as a close listener at it and
deny its
request for becoming closed.

The recreation of the view is a little bit tricky because
the necessary
API currently does not exist (it's in the making though).

We ourselves use the following replacement:
use the loadComponentFromURL() method of the desired frame,
but pass a
parameter "Model" in the MediaDescriptor that
contains a reference to
the model. This will advise the frame loader to use the
existing model
and not creating and loading a new one. You must provide the
valid URL
of the document though (or the stream it was loaded from) to
pass the
type detection and to avoid confusion in the documents'
internal media
descriptor.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project
Lead
Please reply to the list only, nospamforMBAgmx.de is
a spam sink.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Am Donnerstag, den 25.05.2006, 23:17 +0200 schrieb Mathias
Bauer:
> Marc Santhoff wrote:
> 
> > Hi,
> > 
> > I'm asking myself if it is possible to start
implementing the following
> > scenario:
> > 
> > A doc is opened in a frame (and window). On a
command of the user the
> > component attached to the frame is stored
elsewhere to keep the
> > reference and a second document (component) is
loaded into that frame.
> > After a task is done by the user the second
component get's saved and
> > destroyed and the first component is attached to
the frame again.
> > 
> > The goal is to reuse the window presented to the
user with variing
> > contents.
> > 
> > Will this work or am I asking for trouble
regarding attached listeners,
> > dispatch or whatelse?
> 
> A "component" inside a frame comprises a
controller and a model. You can
> not keep the controller without the frame, but you can
keep the model
> and you can use this model later on to recreate a
controller including a
> view from it without reloading the document.

Yes, that's  what I wanted to ask for (not fully tuned to
thinking UNO
atm ;).

> To preserve the model from being closed when its last
controller gets
> destroyed you must register as a close listener at it
and deny its
> request for becoming closed.

Okay.

> The recreation of the view is a little bit tricky
because the necessary
> API currently does not exist (it's in the making
though).

As far as it works, it's okay with me.  Do you
know an issue number
for watching progress on this topic?

> We ourselves use the following replacement:
> use the loadComponentFromURL() method of the desired
frame, but pass a
> parameter "Model" in the MediaDescriptor
that contains a reference to
> the model. This will advise the frame loader to use the
existing model
> and not creating and loading a new one. You must
provide the valid URL
> of the document though (or the stream it was loaded
from) to pass the
> type detection and to avoid confusion in the
documents' internal media
> descriptor.

I'll try that, I remeber seeing this solution in another
thread
recently.

Thank you very much,
Marc


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Marc Santhoff wrote:

>> The recreation of the view is a little bit tricky
because the necessary
>> API currently does not exist (it's in the making
though).
> 
> As far as it works, it's okay with me.  Do you
know an issue number
> for watching progress on this topic?

No, but it will be announced in interface.announce once
it's done.
We wanted to introduce the new API together with adding the
new UNO
features to our models (multiple inheritance interfaces, new
style
service with constructors) but it turned out to be more work
than expected.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project
Lead
Please reply to the list only, nospamforMBAgmx.de is
a spam sink.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

I am still having a running battle with getting the
actual height of a frame.

I thought I had a workaround, but it is buggy, or
probably I am doing something wrong.

If I never mess with the selection then it works. But
as soon as I start setting the selection, it stops
working.

It fails on goto range. I have tried passing goto
range every type of conceivable cursor or range, and I
always get com.sun.star.uno.RuntimeException: no text
selection.

Does anyone have any ideas?

What about a slightly different approach? For example,
if I make the textframe selected is there no way I can
get its height throught the dispatcher? The height is
there in the statusbar.

Thanks and have a good weekend!

#####################

XController xController =
connection.getTextDocument().getCurrentController();

XTextFrame returnVal = ( XTextFrame )
AnyConverter.toObject( XTextFrame.class,
connection.getTextDocument().getCurrentSelection() );

XTextViewCursorSupplier xViewCursorSupplier = (
XTextViewCursorSupplier ) UnoRuntime.queryInterface(
XTextViewCursorSupplier.class, xController );

//get the the  view cursor
XTextViewCursor xViewCursor =
xViewCursorSupplier.getViewCursor();

xViewCursor.gotoRange( xTextFrame.getAnchor(), false );

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection
around 
http://mail.yahoo.com 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Am Freitag, den 26.05.2006, 17:51 +0200 schrieb Mathias
Bauer:
> Marc Santhoff wrote:
> 
> >> The recreation of the view is a little bit
tricky because the necessary
> >> API currently does not exist (it's in the
making though).
> > 
> > As far as it works, it's okay with me.  Do you
know an issue number
> > for watching progress on this topic?
> 
> No, but it will be announced in interface.announce once
it's done.
> We wanted to introduce the new API together with adding
the new UNO
> features to our models (multiple inheritance
interfaces, new style
> service with constructors) but it turned out to be more
work than expected.

I'm looking forward to that.

But the next question is already here:

Is there any way to prevent closing from BASIC? The
XCloseListener is
expected to throw an exception which is not possible from
BASIC, afaik.

Regards,
Marc


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Marc Santhoff wrote:

> Am Freitag, den 26.05.2006, 17:51 +0200 schrieb Mathias
Bauer:
>> Marc Santhoff wrote:
>> 
>> >> The recreation of the view is a little bit
tricky because the necessary
>> >> API currently does not exist (it's in the
making though).
>> > 
>> > As far as it works, it's okay with me.  Do you
know an issue number
>> > for watching progress on this topic?
>> 
>> No, but it will be announced in interface.announce
once it's done.
>> We wanted to introduce the new API together with
adding the new UNO
>> features to our models (multiple inheritance
interfaces, new style
>> service with constructors) but it turned out to be
more work than expected.
> 
> I'm looking forward to that.
> 
> But the next question is already here:
> 
> Is there any way to prevent closing from BASIC? The
XCloseListener is
> expected to throw an exception which is not possible
from BASIC, afaik.

In OOO 2.0.3 we have a solution for this IIRC. I have to
look it up,
don't remember it exactly. But as 2.0.3 isn't available
yet I think
waiting until monday is bearable. 

In the worst case it would be simple to add a small C++ or
Java
component to a package of macros that takes over the task to
lock
documents from basic.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project
Lead
Please reply to the list only, nospamforMBAgmx.de is
a spam sink.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Am Samstag, den 27.05.2006, 12:54 +0200 schrieb Mathias
Bauer:
> Marc Santhoff wrote:
> 
> > Am Freitag, den 26.05.2006, 17:51 +0200 schrieb
Mathias Bauer:
> >> Marc Santhoff wrote:
> >> 
> >> >> The recreation of the view is a
little bit tricky because the necessary
> >> >> API currently does not exist (it's
in the making though).
> >> > 
> >> > As far as it works, it's okay with me.
 Do
you know an issue number
> >> > for watching progress on this topic?
> >> 
> >> No, but it will be announced in
interface.announce once it's done.
> >> We wanted to introduce the new API together
with adding the new UNO
> >> features to our models (multiple inheritance
interfaces, new style
> >> service with constructors) but it turned out
to be more work than expected.
> > 
> > I'm looking forward to that.
> > 
> > But the next question is already here:
> > 
> > Is there any way to prevent closing from BASIC?
The XCloseListener is
> > expected to throw an exception which is not
possible from BASIC, afaik.
> 
> In OOO 2.0.3 we have a solution for this IIRC. I have
to look it up,
> don't remember it exactly. But as 2.0.3 isn't
available yet I think
> waiting until monday is bearable. 

Very nice to hear.  And I have
a relaxed timeframe for this task, even
Tuesday would be fine. ;D

> In the worst case it would be simple to add a small C++
or Java
> component to a package of macros that takes over the
task to lock
> documents from basic.

Okay, this would be possible. But I want to avoid depending
on anything
else if possible at all. If not I would switch to Python as
my scripting
language (writing all libraries anew).

Many thanks,
Marc


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

Mathias Bauer wrote:

> Marc Santhoff wrote:
> 
>> Am Freitag, den 26.05.2006, 17:51 +0200 schrieb
Mathias Bauer:
>>> Marc Santhoff wrote:
>>> 
>>> >> The recreation of the view is a little
bit tricky because the necessary
>>> >> API currently does not exist (it's in
the making though).
>>> > 
>>> > As far as it works, it's okay with me.
 Do
you know an issue number
>>> > for watching progress on this topic?
>>> 
>>> No, but it will be announced in
interface.announce once it's done.
>>> We wanted to introduce the new API together
with adding the new UNO
>>> features to our models (multiple inheritance
interfaces, new style
>>> service with constructors) but it turned out to
be more work than expected.
>> 
>> I'm looking forward to that.
>> 
>> But the next question is already here:
>> 
>> Is there any way to prevent closing from BASIC? The
XCloseListener is
>> expected to throw an exception which is not
possible from BASIC, afaik.
> 
> In OOO 2.0.3 we have a solution for this IIRC. I have
to look it up,
> don't remember it exactly. But as 2.0.3 isn't
available yet I think
> waiting until monday is bearable. 
> 
> In the worst case it would be simple to add a small C++
or Java
> component to a package of macros that takes over the
task to lock
> documents from basic.

A mail was sent to the intefacer-announce ML but until now
didn't
appear. Here's the content:

"To allow to lock an object supporting
::com::sun::star::util::XCloseable or
::com::sun::star::frame::XDesktop using a bridge that does
not support
exceptions a new service
::com::sun::star::embed::InstanceLocker was
implemented.

After creation the service adds a listener of requested type
( close
or terminate ) to the controlled object and let the listener
throw
related veto exception until the service is disposed. It is
also
possible on initialization to provide an object that will be
requested
for approval before throwing the veto exception. This object
could be
useful in case the service is instantiated from another
process, so
that in case the communication with the process is broken
the approval
object is not accessible and the locked object does not stay
locked
forever.

Please take a look in com/sun/star/embed/InstanceLocker.idl
for details."

As you can see you only need to instantiate a service that
"locks" the
document as long as it is alive. In Basic you can use a
global variable
for it. But be careful: you must guarantee that the lock
won't exist
until eternity, otherwise OOo will never terminate and must
be killed.
The same is true if you implement a CloseListener in Java
and always
throw an exception.

Best regards,
Mathias

-- 
Mathias Bauer - OpenOffice.org Application Framework Project
Lead
Please reply to the list only, nospamforMBAgmx.de is
a spam sink.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org