New URLHandler interface

[Oliver Braun]

Hi *,

I propose a new interface for opening URLs in external applications (see
below).

Motivation:

currently the interface XSystemShellExecute is used for this purpose.
However, as this interface is specified, it has a serious issue for
being used from OOo directly:
the caller needs to know if and how to escape the parameter/URL
depending on the OS/desktop OOo is running on.

As a result, the implementation of XSystemShellExecute on Unix currently
violates its specification by escaping the URL itself.

Proposed new API:

module com { module sun { module star { module system {

/* Interface for opening documents referenced by a URL in an
   external application.
*/
interface XURLHandler : com::sun::star::uno::XInterface
{
    /* Passes the given URL to the desktop environment to be opened
       in the users favorite application.

       @param aURL to be opened externally
    */
    void open( [in] string aURL );
}

 }; }; }; };


Open Issues:

Is it o.k. to throw a RuntimeException in the case the desktop
environment does not know how to handle the specified URL, or should we
introduce a new exception for this ?

Feedback appreciated !
Oliver

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

[Philipp Lohmann]

Oliver Braun wrote:
> Open Issues:
>
> Is it o.k. to throw a RuntimeException in the case the desktop
> environment does not know how to handle the specified URL, or should we
> introduce a new exception for this ?

Use an IllegalArgumentException ? Another question: why throw an
exception, why not return a bool for success or not ?

Just my 2 cents, pl

--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
     -- Author unknown

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

[Oliver Braun]

Philipp Lohmann - Sun Germany wrote:

> Oliver Braun wrote:
>  
>> Open Issues:
>>
>> Is it o.k. to throw a RuntimeException in the case the desktop
>> environment does not know how to handle the specified URL, or should we
>> introduce a new exception for this ?
>>    
>
> Use an IllegalArgumentException ?

Because the argument itself may not be the problem, but some broken
configuration on the desktop.

> Another question: why throw an exception, why not return a bool for success or not ?
>  
Don't know (why this did not come to my mind). Sounds reasonable.

Thanks,
Oliver

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

[Stephan Bergmann]

Oliver Braun wrote:

> Hi *,
>
> I propose a new interface for opening URLs in external applications (see
> below).
>
> Motivation:
>
> currently the interface XSystemShellExecute is used for this purpose.
> However, as this interface is specified, it has a serious issue for
> being used from OOo directly:
> the caller needs to know if and how to escape the parameter/URL
> depending on the OS/desktop OOo is running on.
>
> As a result, the implementation of XSystemShellExecute on Unix currently
> violates its specification by escaping the URL itself.
>
> Proposed new API:
>
> module com { module sun { module star { module system {
>
> /* Interface for opening documents referenced by a URL in an
>   external application.
> */
> interface XURLHandler : com::sun::star::uno::XInterface
> {
>    /* Passes the given URL to the desktop environment to be opened
>       in the users favorite application.
>
>       @param aURL to be opened externally
>    */
>    void open( [in] string aURL );
> }
>
> }; }; }; };

Nit: XURLHandler vs. XUrlHandler vs. XUriReferenceHandler vs. ...?  (And
similarly for aURL.  Btw, shocked to discover that
<http://api.openoffice.org/docs/DevelopersGuide/Appendix/IDLDesignGuide/IDLDesignGuide.xhtml#1_2_11_1_Naming>
still recommends messed-up Hungarian, see
<http://www.joelonsoftware.com/articles/Wrong.html>.)

> Open Issues:
>
> Is it o.k. to throw a RuntimeException in the case the desktop
> environment does not know how to handle the specified URL, or should we
> introduce a new exception for this ?

Since this is an anticipated situation, it calls for a
non-RuntimeException.  (Even borders on the exception--not an exception
at all line.)

-Stephan

> Feedback appreciated !
> Oliver

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

[Oliver Braun]

Hi Stephan,

Stephan Bergmann wrote:
> Oliver Braun wrote:
>
> Nit: XURLHandler vs. XUrlHandler vs. XUriReferenceHandler vs. ...?  
> (And similarly for aURL)
I think I go with XUrlHandler as I believe more people are used to the
term "url" than to "uri".
>
> Since this is an anticipated situation, it calls for a
> non-RuntimeException.  (Even borders on the exception--not an
> exception at all line.)
I already agreed with Philipp on this. Now I suggest:

sal_Bool open( [in] string url );

Thanks,
Oliver

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

[bjoern.milcke]

Hi Oliver,

> Hi Stephan,
>
> Stephan Bergmann wrote:
>> Oliver Braun wrote:
>>
>> Nit: XURLHandler vs. XUrlHandler vs. XUriReferenceHandler vs. ...?  
>> (And similarly for aURL)
> I think I go with XUrlHandler as I believe more people are used to the
> term "url" than to "uri".
>>
>> Since this is an anticipated situation, it calls for a
>> non-RuntimeException.  (Even borders on the exception--not an
>> exception at all line.)
> I already agreed with Philipp on this. Now I suggest:
>
> sal_Bool open( [in] string url );

Nitpicking again: in Idl the type should be bool ;-)

-Bjoern

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

[Stephan Bergmann]

Oliver Braun wrote:

> Hi Stephan,
>
> Stephan Bergmann wrote:
>> Oliver Braun wrote:
>>
>> Nit: XURLHandler vs. XUrlHandler vs. XUriReferenceHandler vs. ...?  
>> (And similarly for aURL)
> I think I go with XUrlHandler as I believe more people are used to the
> term "url" than to "uri".
>>
>> Since this is an anticipated situation, it calls for a
>> non-RuntimeException.  (Even borders on the exception--not an
>> exception at all line.)
> I already agreed with Philipp on this. Now I suggest:
>
> sal_Bool open( [in] string url );

Of course, the advantage of using exceptions is that they can transport
additional (polymorphic) information about what went wrong...

-Stephan

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

[Mathias Bauer]

Stephan Bergmann wrote:

> Oliver Braun wrote:
>> Hi Stephan,
>>
>> Stephan Bergmann wrote:
>>> Oliver Braun wrote:
>>>
>>> Nit: XURLHandler vs. XUrlHandler vs. XUriReferenceHandler vs. ...?  
>>> (And similarly for aURL)
>> I think I go with XUrlHandler as I believe more people are used to the
>> term "url" than to "uri".
>>>
>>> Since this is an anticipated situation, it calls for a
>>> non-RuntimeException.  (Even borders on the exception--not an
>>> exception at all line.)
>> I already agreed with Philipp on this. Now I suggest:
>>
>> sal_Bool open( [in] string url );
>
> Of course, the advantage of using exceptions is that they can transport
> additional (polymorphic) information about what went wrong...

And its biggest disadvantage is that it breaks the code in languages
that have no concept to deal with them as e.g. OOo Basic.

That doesn't mean we shouldn't use exceptions but we should perhaps use
them less enthusiastically as we did in the past. Especially as the
advantage you outlined is used only rarely.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[frank.schoenheit]

Hi Mathias,

>>Of course, the advantage of using exceptions is that they can transport
>>additional (polymorphic) information about what went wrong...
>
> And its biggest disadvantage is that it breaks the code in languages
> that have no concept to deal with them as e.g. OOo Basic.
>
> That doesn't mean we shouldn't use exceptions but we should perhaps use
> them less enthusiastically as we did in the past.

Or we should perhaps fix our broken language bindings, which can't make
use of exceptions, which finally are a very basic UNO concept.

> Especially as the advantage you outlined is used only rarely.

I don't think that lazyness of developers is a good argument here :)

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>>>Of course, the advantage of using exceptions is that they can transport
>>>additional (polymorphic) information about what went wrong...
>>
>> And its biggest disadvantage is that it breaks the code in languages
>> that have no concept to deal with them as e.g. OOo Basic.
>>
>> That doesn't mean we shouldn't use exceptions but we should perhaps use
>> them less enthusiastically as we did in the past.
>
> Or we should perhaps fix our broken language bindings, which can't make
> use of exceptions, which finally are a very basic UNO concept.

This is not a matter of the language binding but a matter of missing
support in the language.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[frank.schoenheit]

Hi Mathias,

>> Hi Mathias,
>>
>>>> Of course, the advantage of using exceptions is that they can transport
>>>> additional (polymorphic) information about what went wrong...
>>> And its biggest disadvantage is that it breaks the code in languages
>>> that have no concept to deal with them as e.g. OOo Basic.
>>>
>>> That doesn't mean we shouldn't use exceptions but we should perhaps use
>>> them less enthusiastically as we did in the past.
>> Or we should perhaps fix our broken language bindings, which can't make
>> use of exceptions, which finally are a very basic UNO concept.
>
> This is not a matter of the language binding but a matter of missing
> support in the language.

Call it any way you want :)

As a matter of fact, the scripting language delivered with OOo -
StarBasic - lacks support for one of the most basic features
(exceptions) of one of the central foundations of OOo (UNO).

Looking at our testtool scripts, which are also written in some kind of
Basic very similar to StarBasic, there are constructs such as
"try/catch" - so it should be possible to implement such things without
too much effort (Don't you also hate those people not having any clue,
but saying "this must be simple!"?). "throw" would be a logical
extension of this.

I seriously think we should address this - for better UNO access in
Basic, and on the medium term probably also for better VBA compatibility.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>>> Hi Mathias,
>>>
>>>>> Of course, the advantage of using exceptions is that they can transport
>>>>> additional (polymorphic) information about what went wrong...
>>>> And its biggest disadvantage is that it breaks the code in languages
>>>> that have no concept to deal with them as e.g. OOo Basic.
>>>>
>>>> That doesn't mean we shouldn't use exceptions but we should perhaps use
>>>> them less enthusiastically as we did in the past.
>>> Or we should perhaps fix our broken language bindings, which can't make
>>> use of exceptions, which finally are a very basic UNO concept.
>>
>> This is not a matter of the language binding but a matter of missing
>> support in the language.
>
> Call it any way you want :)
>
> As a matter of fact, the scripting language delivered with OOo -
> StarBasic - lacks support for one of the most basic features
> (exceptions) of one of the central foundations of OOo (UNO).
>
> Looking at our testtool scripts, which are also written in some kind of
> Basic very similar to StarBasic, there are constructs such as
> "try/catch" - so it should be possible to implement such things without
> too much effort (Don't you also hate those people not having any clue,
> but saying "this must be simple!"?). "throw" would be a logical
> extension of this.
>
> I seriously think we should address this - for better UNO access in
> Basic, and on the medium term probably also for better VBA compatibility.

Supported. Volunteers, anyone? ;-)

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[andreas.bregas]

Hi Frank,

>> This is not a matter of the language binding but a matter of missing
>> support in the language.
>
> Call it any way you want :)
>
> As a matter of fact, the scripting language delivered with OOo -
> StarBasic - lacks support for one of the most basic features
> (exceptions) of one of the central foundations of OOo (UNO).

ACK


> Looking at our testtool scripts, which are also written in some kind of
> Basic very similar to StarBasic, there are constructs such as
> "try/catch" - so it should be possible to implement such things without
> too much effort (Don't you also hate those people not having any clue,
> but saying "this must be simple!"?). "throw" would be a logical
> extension of this.

Indeed this belongs to these famous "this must be simple" problems. :-)

Let's start with the testtool. The testtool Basic is not similar
to OOo Basic, it *is* OOo Basic, extended by some testtool speci-
fic commands and some convenience functionality. The try/catch
belongs to the latter. According to Gregor it's only another syn-
tax for the on error functionality that is supported by Basic any-
way. On error also supports UNO exceptions but in a very limited
way. Every UNO exception is mapped to the Basic Runtime Error 1.

So it's possible to identify an error as UNO exception but it's
not possible to identify which exception it is. Example:

Sub Main
         on error goto ErrHdl
         a = 0
         ' print 1 / a
         oLib = BasicLibraries.getByName( "Foo" )
         exit sub

ErrHdl:
         if err = 1 then
                 print "UNO exception"
         else
                 print "Other error"
         end if
End Sub

Assuming there is no Library named Foo this program will print
"UNO exception" as a NoSuchElementExcetption will be thrown.
After uncommenting "print 1 / a" it will print "Other error"
as "Division by zero" has the error code 11.

IIRC there is one main problem to realize a better support, es-
pecially to allow catching specific exceptions: To implement
this in the Basic core a generic catch would have to be used,
as it's not possible to write down catch statements for any
known UNO exception, not to speak of exceptions that will be
designed in the future.

So Basic has to catch a very basic exeption type like:

   ...
}
catch( Exception& e )
{}

Maybe the problem is solved in the mean time, but at least when
I addressed this problem the first time, there was no way to
get the real (UNO) exception type from e. If there is a way now,
e.g. by using C++ RTTI, the implementation of a better exception
support in OOo Basic really shouldn't be too difficult.

A "throw $UNO-Exception-type" statement is easier anyway, as the
UNO type/reflection API can be used to get a type from the type
name. But also this of course has to be evaluated in more detail.


> I seriously think we should address this - for better UNO access in
> Basic, and on the medium term probably also for better VBA compatibility.

I agree that better UNO exception support in OOo Basic would be
good, but I don't see the connection to VBA compatibility. VB(A)
does not support exceptions as far as I know, only On Error.
This is different for VB.net but VB.net != VB(A).

Regards

Andreas

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

[frank.schoenheit]

Hi Andreas,

thanks for the in-depth explanations, see my comments to some items below.

> Let's start with the testtool. The testtool Basic is not similar
> to OOo Basic, it *is* OOo Basic, extended by some testtool speci-
> fic commands and some convenience functionality. The try/catch
> belongs to the latter. According to Gregor it's only another syn-
> tax for the on error functionality that is supported by Basic any-
> way. On error also supports UNO exceptions but in a very limited
> way. Every UNO exception is mapped to the Basic Runtime Error 1.

hey, so we get try/catch for free ;)

> So it's possible to identify an error as UNO exception but it's
> not possible to identify which exception it is.
> ...
> IIRC there is one main problem to realize a better support, es-
> pecially to allow catching specific exceptions:
> ...
> Maybe the problem is solved in the mean time, but at least when
> I addressed this problem the first time, there was no way to
> get the real (UNO) exception type from e. If there is a way now,
> e.g. by using C++ RTTI, the implementation of a better exception
> support in OOo Basic really shouldn't be too difficult.

::cppu::getCaughtException could be used. It returns an Any, which
contains the full exception which has just been caught. Quite
convenient, I use it all the time since I know about it ...

(RTTI won't work since our Exception classes are not polymorphic - since
css.uno.Exception does not have any virtual methods.)

>> I seriously think we should address this - for better UNO access in
>> Basic, and on the medium term probably also for better VBA compatibility.
>
> I agree that better UNO exception support in OOo Basic would be
> good, but I don't see the connection to VBA compatibility. VB(A)
> does not support exceptions as far as I know, only On Error.
> This is different for VB.net but VB.net != VB(A).

Ah, sorry for confusing things here.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[andreas.bregas]

Hi Frank,

>> Let's start with the testtool. The testtool Basic is not similar
>> to OOo Basic, it *is* OOo Basic, extended by some testtool speci-
>> fic commands and some convenience functionality. The try/catch
>> belongs to the latter. According to Gregor it's only another syn-
>> tax for the on error functionality that is supported by Basic any-
>> way. On error also supports UNO exceptions but in a very limited
>> way. Every UNO exception is mapped to the Basic Runtime Error 1.
>
> hey, so we get try/catch for free ;)

At least a beginner's version... :-)


>> Maybe the problem is solved in the mean time, but at least when
>> I addressed this problem the first time, there was no way to
>> get the real (UNO) exception type from e. If there is a way now,
>> e.g. by using C++ RTTI, the implementation of a better exception
>> support in OOo Basic really shouldn't be too difficult.
>
> ::cppu::getCaughtException could be used. It returns an Any, which
> contains the full exception which has just been caught. Quite
> convenient, I use it all the time since I know about it ...

Great, this would solve the problem. Maybe we then should
think about a cheap solution, at least for now. E.g. a spe-
cial object named CurrentUnoException or something like
that could be provided by Basic in case an UNO exception
error occurs containing the Exception object. This would
match with the err variable concept and we wouldn't have
to implement the complete try/catch syntax that isn't
Basic like anyway.

Regards

Andreas

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

[frank.schoenheit]

Hi Andreas,

> Great, this would solve the problem. Maybe we then should
> think about a cheap solution, at least for now. E.g. a spe-
> cial object named CurrentUnoException or something like
> that could be provided by Basic in case an UNO exception
> error occurs containing the Exception object.

+1

> This would
> match with the err variable concept and we wouldn't have
> to implement the complete try/catch syntax that isn't
> Basic like anyway.

Well ... how is "Basic like" defined? By the Basic originally invented
some decades ago, by one of the zillions of Basic dialects out there, or
 by what we me make of it? I certainly vote for the latter ...

We also need, IMO, a "throw". (I think Mathias will agree to me here.
AFAIK, his repeated argueing for exception-less UNO API originates from
his team's experiences with existing API which could not be used in
Basic, since this would have required the script to throw an exception.)
If we would decide to have it, *not* having try/catch would look ...
senseless.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Mathias Bauer]

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Andreas,
>
>> Great, this would solve the problem. Maybe we then should
>> think about a cheap solution, at least for now. E.g. a spe-
>> cial object named CurrentUnoException or something like
>> that could be provided by Basic in case an UNO exception
>> error occurs containing the Exception object.
>
> +1
>
>> This would
>> match with the err variable concept and we wouldn't have
>> to implement the complete try/catch syntax that isn't
>> Basic like anyway.
>
> Well ... how is "Basic like" defined? By the Basic originally invented
> some decades ago, by one of the zillions of Basic dialects out there, or
>  by what we me make of it? I certainly vote for the latter ...
>
> We also need, IMO, a "throw". (I think Mathias will agree to me here.
> AFAIK, his repeated argueing for exception-less UNO API originates from
> his team's experiences with existing API which could not be used in
> Basic, since this would have required the script to throw an exception.)
> If we would decide to have it, *not* having try/catch would look ...
> senseless.

Yes, that's one point. The other point is a missing real "catch"
support. The "On error goto" is not sufficient as it doesn't allow to
specify where the program should continue in case an exception got
caught (except by flooding your code with jump labels and your
"exception handlers" with gazillions of Goto statement).

If we had a usable exception support in OOo Basic we still can have
problems with other languages like e.g. VBA but that might be bearable.

I don't know wether our Scripting Framework and the possible scripting
languages using it support exceptions. Andreas should know better.

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: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

[Juergen Schmidt-3]

Mathias Bauer wrote:

> Frank Schönheit - Sun Microsystems Germany wrote:
>
>> Hi Andreas,
>>
>>> Great, this would solve the problem. Maybe we then should
>>> think about a cheap solution, at least for now. E.g. a spe-
>>> cial object named CurrentUnoException or something like
>>> that could be provided by Basic in case an UNO exception
>>> error occurs containing the Exception object.
>> +1
>>
>>> This would
>>> match with the err variable concept and we wouldn't have
>>> to implement the complete try/catch syntax that isn't
>>> Basic like anyway.
>> Well ... how is "Basic like" defined? By the Basic originally invented
>> some decades ago, by one of the zillions of Basic dialects out there, or
>>  by what we me make of it? I certainly vote for the latter ...
>>
>> We also need, IMO, a "throw". (I think Mathias will agree to me here.
>> AFAIK, his repeated argueing for exception-less UNO API originates from
>> his team's experiences with existing API which could not be used in
>> Basic, since this would have required the script to throw an exception.)
>> If we would decide to have it, *not* having try/catch would look ...
>> senseless.
>
> Yes, that's one point. The other point is a missing real "catch"
> support. The "On error goto" is not sufficient as it doesn't allow to
> specify where the program should continue in case an exception got
> caught (except by flooding your code with jump labels and your
> "exception handlers" with gazillions of Goto statement).
>
> If we had a usable exception support in OOo Basic we still can have
> problems with other languages like e.g. VBA but that might be bearable.
>
> I don't know wether our Scripting Framework and the possible scripting
> languages using it support exceptions. Andreas should know better.

at least JAVA macros work as expected with exceptions ;-)

Juergen

>
> Ciao,
> Mathias
>

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