Macro & ODB documents

[Paolo Mantovani]

Hi all,

As you know, now macros are contained at ODB document level and no more
at subdocument level (forms and reports)
Good to hear. This finally corrects a severe inconsistency affecting
former versions.
However, if you launch a macro from the IDE, ThisComponent points
correctly to the ODB document, but if you launch the same macro from a
button placed into a form-document, ThisComponent points to the
form-document itself.

This is not a small problem: users will soon start looking for a
solution. Most probably many of them will not recognize the exact terms
of the problem, they will just learn that using ThisComponent.Parent
sometimes does the job.
And when this bug will be corrected, all their code will simply stop
working.

But IMHO the real problem is elsewhere:
Normal users (not developers) are struggling with macro in ODB documents
from the beginning.
They fill their OOoBase documents with tons of complicated source code,
that mostly they not even understand, and all this pain just because
they would like to launch a form from another.

Put a simple way to do this job (for example a dedicated property in
form buttons) and 99.99% of OOoBase users will no more need of any macros


ciao
Paolo M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Paolo,

> Good to hear. This finally corrects a severe inconsistency affecting
> former versions.
> However, if you launch a macro from the IDE, ThisComponent points
> correctly to the ODB document, but if you launch the same macro from a
> button placed into a form-document, ThisComponent points to the
> form-document itself.
>
> This is not a small problem: users will soon start looking for a
> solution. Most probably many of them will not recognize the exact terms
> of the problem, they will just learn that using ThisComponent.Parent
> sometimes does the job.
> And when this bug will be corrected, all their code will simply stop
> working.

This is not a bug, this behaves as designed:
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Global_Variables_in_Basic_Macros.

See the discussion page of the spec for a reasoning. One major problem
which would immediately occur if ThisComponent were the DB doc is the
following: Scripts bound to menu or toolbar items, working on the
document from which they're invoked, would need to behave differently
depending on whether they're invoked for a form/report or any other
document type.

If you need access to the database document regardless of the place of
invocation, use ThisDatabaseDocument. If you need access to the
sub/document from which the macro was invoked, use ThisComponent.


> But IMHO the real problem is elsewhere:
> Normal users (not developers) are struggling with macro in ODB documents
> from the beginning.
> They fill their OOoBase documents with tons of complicated source code,
> that mostly they not even understand, and all this pain just because
> they would like to launch a form from another.
>
> Put a simple way to do this job (for example a dedicated property in
> form buttons) and 99.99% of OOoBase users will no more need of any macros

I definitely wouldn't agree to the "99.99%", but for sure that would be
a reasonable extension of the existing functionality. Did you by chance
vote for it when we asked for user input? :)
(http://blogs.sun.com/GullFOSS/entry/if_you_had_3_wishes)

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paolo Mantovani]

Frank Schönheit - Sun Microsystems Germany ha scritto:

> Hi Paolo,
>
>> Good to hear. This finally corrects a severe inconsistency affecting
>> former versions.
>> However, if you launch a macro from the IDE, ThisComponent points
>> correctly to the ODB document, but if you launch the same macro from a
>> button placed into a form-document, ThisComponent points to the
>> form-document itself.
>>
>> This is not a small problem: users will soon start looking for a
>> solution. Most probably many of them will not recognize the exact terms
>> of the problem, they will just learn that using ThisComponent.Parent
>> sometimes does the job.
>> And when this bug will be corrected, all their code will simply stop
>> working.
>
> This is not a bug, this behaves as designed:
> http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents#Global_Variables_in_Basic_Macros.
> See the discussion page of the spec for a reasoning. One major problem
> which would immediately occur if ThisComponent were the DB doc is the
> following: Scripts bound to menu or toolbar items, working on the
> document from which they're invoked, would need to behave differently
> depending on whether they're invoked for a form/report or any other
> document type.

The problem is that forms and report definitions are not documents.
I know, actually they are documents, but this should be an
implementation detail and I hope that in future they will be replaced
from something more suitable than documents.


> If you need access to the database document regardless of the place of
> invocation, use ThisDatabaseDocument. If you need access to the
> sub/document from which the macro was invoked, use ThisComponent.

Thank you for the explanation. I'm sure that I had already read that
specs but I completely missed the ThisDatabaseDocument thing, sorry
I think it is a step back in the consistency of the OOoBase environment
but I guess that backward compatibility reasons have prevailed here.

>
>> But IMHO the real problem is elsewhere:
>> Normal users (not developers) are struggling with macro in ODB documents
>> from the beginning.
>> They fill their OOoBase documents with tons of complicated source code,
>> that mostly they not even understand, and all this pain just because
>> they would like to launch a form from another.
>>
>> Put a simple way to do this job (for example a dedicated property in
>> form buttons) and 99.99% of OOoBase users will no more need of any macros
>
> I definitely wouldn't agree to the "99.99%", but for sure that would be
> a reasonable extension of the existing functionality. Did you by chance
> vote for it when we asked for user input? :)
> (http://blogs.sun.com/GullFOSS/entry/if_you_had_3_wishes)

Sincerely I have no problems launching forms or reports via macro, but
my approach is based on extensions and is not suitable for the majority
of users.
I'm just trying to give some help to Italian users that are asking me to
find some workaround for this very old missing.


Thank you
Paolo M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Paolo,

> The problem is that forms and report definitions are not documents.
> I know, actually they are documents, but this should be an
> implementation detail and I hope that in future they will be replaced
> from something more suitable than documents.

Call them with another word, if you want :)

The problem persists: Imagine an extension which adds a menu item which
should, say, just display the name of the document-or-how-you-call-it
which lives in the frame to which the menu belongs to.

In the current situation, this extension's code can rely on
ThisComponent being the, well, component in the frame to which the menu
belongs. So, whatever it wants to do with the component, it can use
ThisComponent.

If we had ThisComponent point to the database document, then such code
would be more complex, to distinguish between "sub components" and "top
level components".

The basic problem here is that in the past, "ThisComponent" was
effectively used for two different purposes: For a Basic macro which is
embedded in a document, it *always* refers to this document. For a Basic
macro located elsewhere, it *always* refers to the *currently active*
document. (where the problem that "currently active" is not really a
well-defined term across different platforms and window managers shall
be ignored for the moment).

With putting macros into database documents, but allowed to run the
macros from the sub components of the document, this was not possible
anymore, since now you suddenly can invoke, from within one component, a
macro which is embedded into another component. So, we *needed* to
separate those two meanings, the question was just which meaning of
ThisComponent should be preserved.

I still think that defining ThisComponent as "the component from which
the macro was invoked" (as opposed to "the component which the macro is
embedded into") was the better choice, and causes less hassle. Finally,
this means that only newly written code needs to care for the new
concept. If we had changed ThisComponent otherwise, then every existing
code (implementing such a functionality as sketched above) would have
needed to be rewritten.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> I still think that defining ThisComponent as "the component from which
> the macro was invoked" (as opposed to "the component which the macro is
> embedded into") was the better choice, and causes less hassle. Finally,
> this means that only newly written code needs to care for the new
> concept. If we had changed ThisComponent otherwise, then every existing
> code (implementing such a functionality as sketched above) would have
> needed to be rewritten.

I'm not sure that the "new concept" would change a lot at all - except
for those cases where the "old concept" creates an undefined situation
anyway.

The only situation where the "new concept" would be wrong is when a
macro from one document is executed while another one is active.
But perhaps this does not make a lot of sense anyway and we should
forbid that?!

When else do you think that in a common situation where the "old
concept" works fine the "new concept" would introduce a problem?

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paolo Mantovani]

Hi Frank,

Frank Schönheit - Sun Microsystems Germany ha scritto:
> Hi Paolo,
>
>> The problem is that forms and report definitions are not documents.
>> I know, actually they are documents, but this should be an
>> implementation detail and I hope that in future they will be replaced
>> from something more suitable than documents.
>
> Call them with another word, if you want :)

Calling them "documents", the distinction between design-time and
runtime is being lost.
I would call them Form designer and Report designer (at design time) and
runtime form instance (at runtime)
Not necessarily the form designer has to be the same component used for
showing a runtime form instance (IMHO this should be an implementation
detail)

Not necessarily a form/report designer must have an own topframe with UI
elements like menu and toolbars. For example they could be integrated in
the ODB document window.

Speaking of runtime forms, again I don't see the necessity for having
word processor capabilities (menu, toolbars, online help, styles,
navigator and so on).
IMHO a form could be just a simple window that contains data-aware controls.

I ever thought that using writer documents inside database documents was
   more a side effect due to the former OOo1.x approach than a precise
design choiche, but of course this is just my thought.


[....]
> I still think that defining ThisComponent as "the component from which
> the macro was invoked" (as opposed to "the component which the macro is
> embedded into") was the better choice, and causes less hassle. Finally,
> this means that only newly written code needs to care for the new
> concept. If we had changed ThisComponent otherwise, then every existing
> code (implementing such a functionality as sketched above) would have
> needed to be rewritten.

Thank you for explaining the rationale behind your decisions.
As usual you were very detailed and helpful, so thanks for taking the time.

Regarding the ThisDatabaseDocument thing, I'm experimenting.

The open() method is very simple and straightforward and I'm sure that
users will be very happy of it, but I noticed a possible problem.

The open method seems not able to create the first connection. This
means that you can use the open method only for the second form, but you
still have to launch manually a first form.

This makes impossible to use the open() method in order to launch a form
from the OnOpen method for example.

Of course you can still use the "old" loadComponentFromUrl() method but
IMHO it would be better to have a single method that works in every
situation

Thanks
Paolo M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Paolo Mantovani]

Paolo Mantovani ha scritto:
[....]
> This makes impossible to use the open() method in order to launch a form
> from the OnOpen method for example.
            ^^^^^^^^^^^^^
I meant "onDocumentOpen event"

ciao
Paolo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

>> I still think that defining ThisComponent as "the component from which
>> the macro was invoked" (as opposed to "the component which the macro is
>> embedded into") was the better choice, and causes less hassle. Finally,
>> this means that only newly written code needs to care for the new
>> concept. If we had changed ThisComponent otherwise, then every existing
>> code (implementing such a functionality as sketched above) would have
>> needed to be rewritten.
>
> I'm not sure that the "new concept" would change a lot at all - except
> for those cases where the "old concept" creates an undefined situation
> anyway.

Up to 3.0, database documents, and its sub components (forms, reports,
queries, tables, relation designer) didn't participate in the
ThisComponent game (since the implementation of this global property was
purely SFX based). So, if somebody wrote a (global) macro and triggered
this from within one of the DB components/documents, ThisComponent was
effectively undefined.

This scenario - executing such macros from with DB components - is the
only one I know where 3.1 differs from 3.0. So, yes, you're absolutely
right :)

> The only situation where the "new concept" would be wrong is when a
> macro from one document is executed while another one is active.
> But perhaps this does not make a lot of sense anyway and we should
> forbid that?!

This is forbidden already: The "Run Macro" dialog lists the global
macros, plus the ones from the current document, nothing else.

It is of course still possible to programmatically execute a macro which
resides in a non-current document, and therein, ThisComponent points to
the embedding doc, not the active one.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Paolo,

> Not necessarily the form designer has to be the same component used for
> showing a runtime form instance (IMHO this should be an implementation
> detail)
> ...
> Speaking of runtime forms, again I don't see the necessity for having
> word processor capabilities (menu, toolbars, online help, styles,
> navigator and so on).
> IMHO a form could be just a simple window that contains data-aware controls.
>
> I ever thought that using writer documents inside database documents was
>    more a side effect due to the former OOo1.x approach than a precise
> design choiche, but of course this is just my thought.

I'm absolutely with you, and if I'm lobbying for years for replacing the
Writer-based forms designer with dialog-based ones :)

> Not necessarily a form/report designer must have an own topframe with UI
> elements like menu and toolbars. For example they could be integrated in
> the ODB document window.

You're talking about MDI (multiple document interface) here, as opposed
to SDI (single document interface).

This was one design decision we had to make when Base was created in the
current form. Finally, the decision for SDI was because of technical
constraints, since OOo doesn't have an infrastructure for MDI.

Yes, MDI would have prevented the irritation around ThisComponent. On
the other hand, we would have needed a new mechanism to obtain the
"current sub frame of the ODB document window". You see, it always boils
down to the final problem that ThisComponent had two meanings in 3.0,
which by accident fell together all the time. With macros in database
documents, those two meanings ("embedding document" and "active (sub)
component") were separated, so no matter the design, another term
besides ThisComponent is needed.

I'll answer the remaining part of your mail separately.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Paolo,

> Regarding the ThisDatabaseDocument thing, I'm experimenting.
>
> The open() method is very simple and straightforward and I'm sure that
> users will be very happy of it, but I noticed a possible problem.

Not sure which open method you refer to, ThisDatabaseDocument doesn't
have one.

> The open method seems not able to create the first connection. This
> means that you can use the open method only for the second form, but you
> still have to launch manually a first form.
>
> This makes impossible to use the open() method in order to launch a form
> from the OnOpen method for example.

If you want to open a form (in the sense of: display UI) when the
document loads, you should use methods at the *controller* of the
document, not at the document. For this, XDatabaseDocumentUI [1] should
be used. It provides functionality which effectively mimics user input.

So, something like
  oController = ThisDatabaseDocument.CurrentController
  If ( Not oController.isConnected() ) Then
    oController.connect()
  End If
  oController.loadComponent( "my form", _
    com.sun.star.sdb.application.DatabaseObject.FORM,
    FALSE  ' not for editing, but for data entry
  )
should do what you want.

Ciao
Frank

[1]http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/application/XDatabaseDocumentUI.html



--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Fernand Vanrie]

Hallo Frank , pronto Paolo

Interesting discussion,  I  learned from my first real live frontend
application to minimize the number of  FORM and SUBFORMS and then using
DIALOGS  to pass data from or  to the Tables.
BTW: oController.loadComponent( "my form",  
com.sun.star.sdb.application.DatabaseObject.FORM,FALSE )
 do not works , must be:
oController.loadComponent(com.sun.star.sdb.application.DatabaseObject.FORM,
"my form",FALSE )

greetz

Fernand

> Hi Paolo,
>
>  
>> Regarding the ThisDatabaseDocument thing, I'm experimenting.
>>
>> The open() method is very simple and straightforward and I'm sure that
>> users will be very happy of it, but I noticed a possible problem.
>>    
>
> Not sure which open method you refer to, ThisDatabaseDocument doesn't
> have one.
>
>  
>> The open method seems not able to create the first connection. This
>> means that you can use the open method only for the second form, but you
>> still have to launch manually a first form.
>>
>> This makes impossible to use the open() method in order to launch a form
>> from the OnOpen method for example.
>>    
>
> If you want to open a form (in the sense of: display UI) when the
> document loads, you should use methods at the *controller* of the
> document, not at the document. For this, XDatabaseDocumentUI [1] should
> be used. It provides functionality which effectively mimics user input.
>
> So, something like
>   oController = ThisDatabaseDocument.CurrentController
>   If ( Not oController.isConnected() ) Then
>     oController.connect()
>   End If
>   oController.loadComponent( "my form", _
>     com.sun.star.sdb.application.DatabaseObject.FORM,
>     FALSE  ' not for editing, but for data entry
>   )
> should do what you want.
>
> Ciao
> Frank
>
> [1]http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/application/XDatabaseDocumentUI.html
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Fernand,

> BTW: oController.loadComponent( "my form",  
> com.sun.star.sdb.application.DatabaseObject.FORM,FALSE )
>  do not works , must be:
> oController.loadComponent(com.sun.star.sdb.application.DatabaseObject.FORM,
> "my form",FALSE )

Uhm, sorry, and thanks for fixing it :)

Ciao
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>>> I still think that defining ThisComponent as "the component from which
>>> the macro was invoked" (as opposed to "the component which the macro is
>>> embedded into") was the better choice, and causes less hassle. Finally,
>>> this means that only newly written code needs to care for the new
>>> concept. If we had changed ThisComponent otherwise, then every existing
>>> code (implementing such a functionality as sketched above) would have
>>> needed to be rewritten.
>>
>> I'm not sure that the "new concept" would change a lot at all - except
>> for those cases where the "old concept" creates an undefined situation
>> anyway.
>
> Up to 3.0, database documents, and its sub components (forms, reports,
> queries, tables, relation designer) didn't participate in the
> ThisComponent game (since the implementation of this global property was
> purely SFX based). So, if somebody wrote a (global) macro and triggered
> this from within one of the DB components/documents, ThisComponent was
> effectively undefined.
>
> This scenario - executing such macros from with DB components - is the
> only one I know where 3.1 differs from 3.0. So, yes, you're absolutely
> right :)
>
>> The only situation where the "new concept" would be wrong is when a
>> macro from one document is executed while another one is active.
>> But perhaps this does not make a lot of sense anyway and we should
>> forbid that?!
>
> This is forbidden already: The "Run Macro" dialog lists the global
> macros, plus the ones from the current document, nothing else.

You still can execute the macros from "Tools-Macro-Organize".

> It is of course still possible to programmatically execute a macro which
> resides in a non-current document, and therein, ThisComponent points to
> the embedding doc, not the active one.

Yes, this is the "old" concept. I thought you wanted to change that. And
in that case we would have a different behavior here. But that would be
bearable, IMHO. We could define that as "undefined". :-)

So indeed your case is the only relevant case where both concept lead to
different behavior. If you think that the new concept fits better to
that (is that true and what will your users think about that?), we can
think about a change.

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> This was one design decision we had to make when Base was created in the
> current form. Finally, the decision for SDI was because of technical
> constraints, since OOo doesn't have an infrastructure for MDI.

Chosing SDI in favor of MDI was not because we didn't have an
infrastructure for MDI (we could have created one, we already had two
different ones in the past ;-)), it was done by intent. SDI enables
better integration into the Desktop and into other applications. I don't
want to argue here whether this decision was a good one or not, I just
want to prevent the impression we would have done something because we
were not able to do differently.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

>> This was one design decision we had to make when Base was created in the
>> current form. Finally, the decision for SDI was because of technical
>> constraints, since OOo doesn't have an infrastructure for MDI.
>
> Chosing SDI in favor of MDI was not because we didn't have an
> infrastructure for MDI (we could have created one, we already had two
> different ones in the past ;-)), it was done by intent. SDI enables
> better integration into the Desktop and into other applications.

I beg to disagree. When we decided to "promote" Base to an own top-level
application (this was back in 2.0 times), we considered SDI vs. MDI. And
IIRC, the iTeam had a slight favor towards MDI - which for a document
with sub components seems more natural, your arguments about desktop
integration do not really hold here IMO. However, since the task itself
was big enough, and at that time, even the SDI infrastructure - as far
as UNO was concerned, and we deliberately decided to use the UNO and not
the SFX framework - was not completely mature, we decided against MDI.

Ciao
Frank


--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Mathias,

>> This is forbidden already: The "Run Macro" dialog lists the global
>> macros, plus the ones from the current document, nothing else.
>
> You still can execute the macros from "Tools-Macro-Organize".

Ah, right. I thought that was forbidden, too. I remember having seen
some error dialog when you execute a macro contained in a non-active
document, but I can't find it anymore (I supposed it was from the macro
organizer).

>> It is of course still possible to programmatically execute a macro which
>> resides in a non-current document, and therein, ThisComponent points to
>> the embedding doc, not the active one.
>
> Yes, this is the "old" concept. I thought you wanted to change that. And
> in that case we would have a different behavior here. But that would be
> bearable, IMHO. We could define that as "undefined". :-)
>
> So indeed your case is the only relevant case where both concept lead to
> different behavior. If you think that the new concept fits better to
> that (is that true and what will your users think about that?), we can
> think about a change.

I don't see any reason to change. All I described here was done quite
some time ago (with being visible the first time in OOo 3.1), and when I
did the implementation for macros in DB docs, I took big care to not
change any ThisComponent related behavior for the other applications. I
in fact think users would kill us if we would :)

Ciao
Frank


--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>>> This was one design decision we had to make when Base was created in the
>>> current form. Finally, the decision for SDI was because of technical
>>> constraints, since OOo doesn't have an infrastructure for MDI.
>>
>> Chosing SDI in favor of MDI was not because we didn't have an
>> infrastructure for MDI (we could have created one, we already had two
>> different ones in the past ;-)), it was done by intent. SDI enables
>> better integration into the Desktop and into other applications.
>
> I beg to disagree. When we decided to "promote" Base to an own top-level
> application (this was back in 2.0 times), we considered SDI vs. MDI. And
> IIRC, the iTeam had a slight favor towards MDI - which for a document
> with sub components seems more natural, your arguments about desktop
> integration do not really hold here IMO. However, since the task itself
> was big enough, and at that time, even the SDI infrastructure - as far
> as UNO was concerned, and we deliberately decided to use the UNO and not
> the SFX framework - was not completely mature, we decided against MDI.

AFAIR having MDI for Base while staying with SDI for other applications
of OOo wasn't an option that had any chance to get implemented. If we
wanted system MDI windows where available, that was even impossible.

So the decision we had to make in every case was: should OOo as a whole
use MDI or SDI. And in that context we always wanted to have SDI, for
the reasons explained.

Whether sfx was used or not is totally irrelevant in that regard. With
sfx we could have used floating windows as child windows for the
different parts of "Base". IIRC we indeed discussed that and abandoned
that idea for varous reasons, but that wasn't MDI, as floating windows
have a different relationship to their application window as MDI windows
have (e.g. wrt. focus treatment, toolbar and other tool windows handling).

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...