Questions about com.sun.star.awt.MenuBar and com.sun.star.awt.PopupMenu

Hi people,

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!)!

THEN, some questions about the code examples:

************************************************************
****************

* FIRST QUESTION: On the API reference, I always founded the
XMenu and
XPopupMenu interfaces (and related ones), but as there is no
service
specification at all, I just didn't know how to instantiate
this
interfaces. Well, now I've learn that the services names
used in the
examples are

"stardiv.Toolkit.VCLXMenuBar" and
"stardiv.Toolkit.VCLXPopupMenu"

At first sight, they look like the implementation names you
use
internally, but not like service names published as UNO
services, I
mean, com.sun.star.awt.MenuBar, and
com.sun.star.awt.PopupMenu

But to my surprise, I used
XComponentContext::getServiceManager() to get
the XMultiComponentFactory, then used its method
getAvailableServiceNames() and got a sequence that DOES
contain these
service names:

"com.sun.star.awt.MenuBar"
"com.sun.star.awt.PopupMenu"
"stardiv.vcl.MenuBar"
"stardiv.vcl.PopupMenu"

And we can use any of the names:

1. "com.sun.star.awt.PopupMenu"
2. "stardiv.vcl.PopupMenu"
3. "stardiv.Toolkit.VCLXPopupMenu"

as they instantiate the same type.

And again to my surprise,
"com.sun.star.awt.MenuBar" and
"com.sun.star.awt.PopupMenu" are not included on
OOo2.3 SDK API
reference, nor in the source/offapi/com/sun/star/awt IDL
files.

So, are they going to be included in the API? Is it safe to
use them?
What service name shall we use, out of the tree options?
Since which OOo
version can they be used?

************************************************************
*********

* SECOND QUESTION: the excellent example uses a fixed text
control to
execute the PopupMenu. I played with an implementation of
the dbaccess
SQL Direct dialog: I wanted to add a pop up menu to the edit
control to
insert SQL templates in it (just like OOo Math commands
window's context
menu).

You can find a picture of the result here:

http://www.arielconstenlahaile.com.ar/o
oo/temp/DBExtras_XSQLDirect_04.png


But I found some problems: when I right click on the edit
control
window, my implementation of the XMouseListener isn't call
first, but
the edit control own implementation, and it consumes the
event,
executing its context menu (the "Paste/Select
all/Special chars". one),
and my XMouseListener  implementation gets called just if I
right clik
on that context menu.

The problem here: FIRST the context menu of the edit control
is
executed, THEN my pop up menu IF I right click on this
context menu.
What I really need here is an XContextMenuInterceptor, but
how do I get
the XContextMenuInterception for the edit control when it
has no
com.sun.star.frame.Controller ? (as long as I know,
UnoControls
implement the Model-View Paradigm, NOT the
Frame-Controller-Model Paradigm)


The example on the SDK works OK, because the fixed text
implementation
has no context menu, but how do I intercept the context menu
of
UnoControls? Is it possible at all? (I mean, using API, not
hacking
OOo's C++ code).


************************************************************
****************


Well, that's all! Sorry for the extension, but maybe someone
gets
something useful from this!


Bye and thanks!



-- 
Ariel Constenla-Haile
La Plata, Argentina

ariel.constenla.hailegmail.com
arielarielconstenlahaile.com.ar

http://www
.arielconstenlahaile.com.ar/ooo/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org

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

ariel.constenla.hailegmail.com
arielarielconstenlahaile.com.ar

http://www
.arielconstenlahaile.com.ar/ooo/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org