Sorry for coming along late.

I would be interested in the package, and just don't see where it is
available. If possible could you send a copy to me, or is you like to wait
for the oxt version that is fine.

Thanks

Drew

On 9/13/07, Frederick Frazelle <[EMAIL PROTECTED]> wrote:
>
> Ariel...  i had such a hard time with your package
> that i decided to wait a while...
>     i'm glad that i saw this today...
>
> "When I finish my reserch, I will ship it as an
> extension (of course the
>
> jar alone can be shipped, but it is too poor: create
> the aliases in
> every ODB everytime is annoing!)."
>
>   Again, THANKS!  -- greetings, fred
>
> *************************************************
>
> --- Ariel Constenla-Haile
> <[EMAIL PROTECTED]> wrote:
>
> > Hi Frank,
> >
> > Frank Schönheit - Sun Microsystems Germany escribió:
> > > Hello Ariel,
> > >
> > >> Date calculation is one of the missing things in
> > HSQLDB: there is the
> > >> DATEDIFF function, but it lacks of other
> > important function present in
> > >> important RDBMS: DATE_ADD, DATE_FORMAT, etc.
> > >> Besides, the string formating of dates is made by
> > default to en-US [1].
> > >>
> > >> I found a solution for my personal needs, let me
> > tell you:
> > >> ...
> > >> after all this I wrote my own SQL functions in
> > Java:
> > >> ...
> > >> I send you the JAR file and an ODB to test it.
> > >
> > > Hey, this is really cool!
> > >
> > > And brings me to: Did you already play with making
> > this an extension? As
> > > I understand it, you should be able to create an
> > .oxt which contains the
> > > JAR, and thus adds the functions to any OOo
> > installation.
> >
> > Yes, and added some things:
> >
> > 1. add a AWT dialog with an edit control to display
> > the .script
> > content (it shows in its first lines the create
> > alias ... statements).
> > What I do is dump the script in the user temp. dir.,
> > read the
> > content, and display it in the dialog. The user can
> > save the script via
> > FilePicker where he/she wants.
> >
> > 2. add an own configuration schema to store user
> > preferences (for
> > example to decide if he/she wants an XJob to create
> > the aliases every
> > time he/she opens an embedded db., aliases, etc.)
> >
> > 3. add a tool bar button to execute the CREATE ALIAS
> > FOR "..."
> > commands ( read the ALIASes and the function names
> > from the extension
> > configuration node)
> >
> > 4. add a wizard where the user can choose which
> > aliases to
> > create/execute for the functions shipped with the
> > extension, and he/she
> > can add his/her own functions (or simply change the
> > aliases I suggested,
> > or give new/localized aliases to HSQLDB functions).
> > All this is to be
> > written into the extension's configuration node path
> >
> >
> >
> > Some problems I've found and I'm working in them:
> >
> > * Unfortunatelly, I've tried to get the locale for
> > the date formatting
> > functions from OOo configuration node; but I've
> > experienced some
> > crashes, so I get the default/system locale of the
> > JVM, what isn't
> > really a "prytty thing", because OOoLocale and the
> > JVM default locale
> > CAN BE DIFFERENT.
> > My hypothesis: we have to proccesses, HSQLDB and
> > OOo. When my Java
> > methods are invoked from OOo, it's HSQLDB that
> > invokes them. In order to
> > get the locale from the configuration, I must
> > bootstrap the Office,
> > because I don't get any XComponentContext or any
> > other OOo API interface
> > to get the Service manager as I would have if my
> > extension component was
> > called from the ProtocolHandler or the Job
> > environment: it's HSQLDB who
> > is invoking them, NOT OOo.
> > I guess it crashes when I try to bootstrap because
> > HSQLDB can't
> > find/load the API JARs.
> > So, I should  ship the required JARS with my
> > extension OXT file, as if
> > it was a client application (?), I should include in
> > my JAR ALL the
> > classes required for a client app. (?), and should
> > also
> > include the dymanics libraries for the diferent OSs
> > (?) :-( .
> >
> >
> > * as in my testing with a database containing some
> > binary files (some
> > pics == script.length()= 1,565,309) I discovered
> > that the edit control
> > has some length limits, I added the posibility to
> > directlly open the
> > script in a Writer doc. instead of the dialog.
> > The problem here is that the actual length limit
> > isn't documented in the API refrence, and is
> > independient from the
> > setMaxTextLen() method in interface
> > :com::sun::star::awt::XTextComponent, and seems to
> > be binding-dependent
> > Here I must find the exact max. text length, in
> > order to advise the user
> > that the script displayed in the AWT isn't fully
> > displayed.
> >
> >
> > When I finish my reserch, I will ship it as an
> > extension (of course the
> > jar alone can be shipped, but it is too poor: create
> > the aliases in
> > every ODB everytime is annoing!).
> >
> >
> > Bye and thanks
> > Ariel
> >
> >
> >
> > --
> > Ariel Constenla-Haile
> > La Plata, Argentina
> >
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> >
> > http://www.arielconstenlahaile.com.ar/ooo/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
> "En el jardin de tu corazón, no plantes sino la rosa del
> amor."  Bahá´u´lláh
>
> Fundación Anisa, A.C. www.fundacionanisa.org ; [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to