Am Sonntag, den 04.11.2007, 22:09 +0100 schrieb Frank Schönheit - Sun
Microsystems Germany:
Hi Ariel,
This would be a great idea!!! (though what about backwards
compatibility? will it be too much code to implement - not to destroy
the users old data?)
meditated a little about this
Hi Frank,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
I forgot to add: I prefer to wait AND have a well-designed
implementation, that releasing something fast just to have a new future
(this way we end up with a tree control that has childs on demand
Uhoh. The tree
Ariel Constenla-Haile wrote:
Hi Frank
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
I'd say the latter. I don't really see the need for calling from form A
into form B: If you have code needed in both forms, put it into the
database document. I think cross-document calling
Hi Andrew,
Andrew Jensen escribió:
Which brings me to another idea I had: Just disallow macros in
forms/reports, only allow them in the database. This would solve most of
the problems :)
This would be a great idea!!!
This was what I thought when I knew that ODB doc. will have macros:
bye
Ariel Constenla-Haile wrote:
Hi Andrew,
Andrew Jensen escribió:
Which brings me to another idea I had: Just disallow macros in
forms/reports, only allow them in the database. This would solve
most of
the problems :)
This would be a great idea!!! This was what I thought when I knew
that
Hi Andrew,
Andrew Jensen escribió:
Ariel Constenla-Haile wrote:
Hi Andrew,
Andrew Jensen escribió:
Which brings me to another idea I had: Just disallow macros in
forms/reports, only allow them in the database. This would solve
most of
the problems :)
This would be a great idea!!! This
Hi people, hi Frank,
as I'm not a blog-guy, I discovered (may be too late) Frank's entry on
GullFOSS
http://blogs.sun.com/GullFOSS/tags/base
These are some questions I had when reading the blog:
* concerning the script URI, have you reached a final conclusion here? I
agree with Frank that
Hi Frank,
Frank Schönheit escribió:
Hi Ariel,
* concerning the script URI, have you reached a final conclusion here?
no.
...
It will be very likely that users will have subroutines with the same
name in a form and in its parent ODB document. Without adding anything
new, wouldn't it be
Ariel Constenla-Haile wrote:
Hi people, hi Frank,
as I'm not a blog-guy, I discovered (may be too late) Frank's entry on
GullFOSS
http://blogs.sun.com/GullFOSS/tags/base
These are some questions I had when reading the blog:
* concerning the script URI, have you reached a final conclusion
Ariel Constenla-Haile wrote:
A suggestion: let's say we have a macro assigned to some event of a
command btn. inside a form.
vnd.sun.star.script:Standard.Module1.Main?language=Basiclocation=document
Well, that's the way most users do things fast: just leave the default
names that OOo
Hi Ariel,
I wanted to mean: once I embed my Jar (and the parcel-descriptor.xml),
will we be able to see it when trying to bind it to a control's event in
the GUI?
I answer myself: as you are using the same components as the other
apps., we should - in theory - be able to perform event
Hi Andrew,
This URI is ambiguous, it points to the Main subroutine in the Module1
of the Standard basic library, but WHERE? inside the form-document or
inside the main ODB document?
IMO, it is not ambiguous at all: A proper address does not end with
library name, module name, method
Hi Andrew,
* concerning the script URI, have you reached a final conclusion here?
I agree with Frank that a adding a new value for the location
parameter isn't the best idea.
Why? What would be wrong with having a location of 'container', for
instance. All the other designators mean
Hi Frank, Andrew,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Andrew,
* concerning the script URI, have you reached a final conclusion here?
I agree with Frank that a adding a new value for the location
parameter isn't the best idea.
Why? What would be wrong with having a
Andrew Jensen wrote:
You simply have to get a reference to the forms script provider.
Dim aArgs(0) As New com.sun.star.beans.PropertyValue
Dim oForm as variant
Dim oScriptProvider as variant
Dim oMethod as variant
oForm = db.forms.looadfromURL( Form1, .)
' get form ScriptProvider
Hi Drew,
Andrew Jensen escribió:
Ariel Constenla-Haile wrote:
Hi Frank, Andrew,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Andrew,
* concerning the script URI, have you reached a final conclusion
here? I agree with Frank that a adding a new value for the location
parameter
Hi Ariel,
I forgot to add: I prefer to wait AND have a well-designed
implementation, that releasing something fast just to have a new future
(this way we end up with a tree control that has childs on demand
Uhoh. The tree control API was developed by somebody else, but he
extensively
Hi Andrew,
Well, don't know about how much code gets touched of course, but if I
copy the form and rename it I would like the calls to the scripts to go
to the newly named form not the old one - without having to change each
and every reference.
Good point. Which means in that scenario,
Hi Ariel,
Just to add a point: we are talking about the URI to be used by the
scripting framework.
There is also another problem:
what will happen when calling a subroutine/function from within the
odb/forms?
will we be able to call a function located in an embedded form-document
from
19 matches
Mail list logo
