Hi Frank,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
FIRST of all, I would like to thank the one who wrote the code of the
GUI examples on the new SDK
(OpenOffice.org_2.3_SDK/examples/DevelopersGuide/GUI): it answers some
questions I had for a long time! Thanks hr (I don't know your real name!)!
Hehe. hr (Jens-Heiner Rechtien) is a release engineer, who integrated
the child workspace where this was introduced. While he, as all our
release engineers, surely deserves thanks for the work he does, in this
particular case please direct your thank to Jürgen Schmidt (jsc, also to
be seen in the CVS history).
As I never use CVS for OOo, I just took for granted that the author of
the *.java source file was the one indicated there, so here I go again:
I would like to thank Jürgen Schmidt for the code of the GUI examples on
the new SDK: it answers some questions I had for a long time! Thanks
Jürgen!!!
The stardiv.* versions are in there for compatibility reasons only, and
should definitely not be used. com.sun.star.awt.* is the name to use, in
any case.
Yes, I thought this too, so the title of this mail ;-)
but as the examples use the stardiv.* version, I thought that may be (as
this services are not even unpublished in the IDL) until they come out
to the world we should use this stardiv. names :-(
I am not sure why they're not documented in the IDL reference, I suppose
they easily could. You might want to submit an issue for this.
I will tomorrow
XContextMenuInterception is not implemented by UNO controls at all. I
did not yet read about this interface in the developer's guide, but I
suppose it can be implemented outside the frame/controller/model
paradigm - but this simply isn't done ATM.
Is the dialog whose screen shot you showed completely done in UNO?
Yes, 100% AWT UnoControlDialog and the like, created at runtime (it
looks like the dbaccess implementation just because I adapted the C++
source code to API in Java; even if had chosen C++ bridge, I would have
done it using just API, as this is the best practice for extensions to
use only API, no VCL or the like, even if you're implementing in C++)
For the timing problem:
Unfortunately, your mouse listeners, though called *first* (technically)
are notified asynchronously. That is, the edit control gets the mouse
click, starts the asynchronous notification of your mouse handler, and
then opens its own context menu. When this is already open, the
notification to your handler arrives.
Thanks for that details!
I fear there's no way how to work around this, there's simply no
mechanism in the code AFAIK.
You might get tired of this suggestion you hear too often from me :),
Honestly NOT: not tired, nor disappointed! At least this process is open
and public, and comes to an (I hope) happy ending (others companies
would have give me a kick down there!)
but I in fact suggest submitting an RFE which requests the
implementation of XContextMenuInterception for UNO controls.
I think that this isn't the place to post some thoughts about OOo
extensions (and their future), as now we have an own mailing list for
that, so I will just say: when I think of extensions, I think of
Firefox/Thunderbird; if OOo wants to go this paradigmatic direction,
OOo should give to extensions developers the capability to fully
manipulate OOo using just the API; in the case we are talking about:
this means that in every implementation where OOo shows a context menu,
there should be an API way to intercept this one (because the way I
understand extensions, even if you are implementing in C++, you
shouldn't use OOo internal code, code not supported by the API: this
would be just like having to rewrite OOo native C++ code and make your
own build to be able to install your extension; but an extension like
this is NO extension at all )
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]
