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
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 po
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
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 w
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 newl
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 su
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 unsubscrib
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 t
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, onl
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.
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.Databas
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
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,
>>>
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
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
> inf
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 di
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
17 matches
Mail list logo
