Hi Carsten,
Carsten Driesner escribió:
Second, with the com.sun.star.frame.FrameControl I do not understand:
1. why isn't it in the toolkit module css.awt, instead of the css.frame
module? although it is a *frame* control, it is a *control*.
This feature is very old and was created for some special cases without
having toolkit in mind. It was extended to be a control. I don't know
why the developer chose css.frame instead of css.awt, that was before I
joined Sun.
"very old"? I thought it was newer, as it really simplifies how to make
a preview window inside a Uno dialog (no need to create a window/frame/etc.)
But looking now at the source: FrameControl::impl_createFrame() in
UnoControls/source/controls/framecontrol.cxx 533-590 looks form the
stone-age: it uses the dispatch mechanism to load the component instead
of XComponentLoader::loadComponentFromURL()
This control was deprecated a while ago so the GUI chapter doesn't
provide information for it. Due to the fact that we don't have a
replacement it was decided to de-deprecate it.
I see, as in the IDL there is no deprecated tag for this I assumed I can
use it.
Third (and last for now): com.sun.star.awt.UnoControlContainer and
com.sun.star.awt.UnoControlContainerModel go beyond my understanding,
although I've been using them so far this way
- instantiate both at the global service manager
- set the model at the control
- add the control to a parent XControlContainer
It turns out that the model can be instantiated at the dialog model's
XMultiServiceManager (obviously just because it supports
UnoControlModel), and then be inserted by name in the dialog model's
XNameContainer.
But when the control model is instantiated this way, there is no control
at all: XControlContainer::getControl() at the UnoControlDialog returns
null.
The control is the "view" of the control model. If you insert a model
there is no view. The view will be created on demand when you call
execute() at XDialog.
right after instantiating a control model at the dialog model factory,
and inserting it by name in the dialog model container,
XControlContainer::getControl() at the UnoControlDialog DOES RETURN a
valid reference to the control of the model just inserted in every
control model I've used so far.
This is how I've been working up to now, and how the wizards work since
they where developed:
*ALL* insertXxx() methods in
wizards/com/sun/star/wizards/ui/UnoDialog.java use the following
strategy [mutatis mutandi the same is valid for all methods in
UnoDialog2.java]:
* first instantiate a control model at the dialog model,
* insert in by name at the dialog model container
* get it by name at the dialog contanier
* return a reference to the main interface of the control, for example
XButton when creating a UnoControlButton/Model:
public XButton insertButton(String sName, int iControlKey,
XActionListener xActionListener, String[] sProperties, Object[] sValues)
throws com.sun.star.uno.Exception {
Object oButtonModel =
insertControlModel("com.sun.star.awt.UnoControlButtonModel", sName,
sProperties, sValues);
XPropertySet xPSet = (XPropertySet)
UnoRuntime.queryInterface(XPropertySet.class, oButtonModel);
xPSet.setPropertyValue("Name", sName);
Object objectButton = xDlgContainer.getControl(new String(sName));
XButton xButton = (XButton)
UnoRuntime.queryInterface(XButton.class, objectButton);
if (xActionListener != null)
xButton.addActionListener(xActionListener);
Integer ControlKey = new Integer(iControlKey);
if (ControlList != null)
ControlList.put(sName, ControlKey);
return xButton;
}
public XInterface insertControlModel(String ServiceName, String sName,
String[] sProperties, Object[] sValues) {
try {
XInterface xControlModel = (XInterface)
MSFDialogModel.createInstance(ServiceName);
Helper.setUnoPropertyValues(xControlModel, sProperties,
sValues);
xDlgNames.insertByName(sName, xControlModel);
return xControlModel;
} catch (com.sun.star.uno.Exception exception) {
exception.printStackTrace(System.out);
return null;
}
}
So I don't see a reason why in the case of the UnoControlContainerModel,
I get a null reference in XControlContainer::getControl().
With *ALL* the following control model this work-flow works (which by
the way is the same suggested in the GUI chap.)
"com.sun.star.awt.UnoControlButtonModel"
"com.sun.star.awt.UnoControlCheckBoxModel"
"com.sun.star.awt.UnoControlComboBoxModel"
"com.sun.star.awt.UnoControlCurrencyFieldModel"
"com.sun.star.awt.UnoControlDateFieldModel"
"com.sun.star.awt.UnoControlEditModel"
"com.sun.star.awt.UnoControlFileControlModel"
"com.sun.star.awt.UnoControlFixedLineModel"
"com.sun.star.awt.UnoControlFixedTextModel"
"com.sun.star.awt.UnoControlFormattedFieldModel"
"com.sun.star.awt.UnoControlGroupBoxModel"
"com.sun.star.awt.UnoControlImageControlModel"
"com.sun.star.awt.UnoControlListBoxModel"
"com.sun.star.awt.UnoControlNumericFieldModel"
"com.sun.star.awt.UnoControlPatternFieldModel"
"com.sun.star.awt.UnoControlProgressBarModel"
"com.sun.star.awt.UnoControlRadioButtonModel"
"com.sun.star.awt.UnoControlRoadmapModel"
"com.sun.star.awt.UnoControlScrollBarModel"
"com.sun.star.awt.UnoControlSimpleAnimationModel"
"com.sun.star.awt.UnoControlSpinButtonModel"
"com.sun.star.awt.UnoControlThrobberModel"
"com.sun.star.awt.UnoControlTimeFieldModel"
"com.sun.star.awt.tree.TreeControlModel"
so why it does not work with the
"com.sun.star.awt.UnoControlContainerModel"?
Obviously, the right [or the only one that works] method for using
this control is creating it at the global service manager. Isn't this
inconsistent with all the rest of the toolkit API?
Yes, that's right and it has historical reasons I explained above.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/GUI/Common_Workflow_to_add_Controls
Isn't this how *all* UNO AWT controls should consistently be design to
work with?
Yes, you are right.
Unfortunately due to other important work I am not able to work
consistently on the toolkit project. Therefore I need volunteers who
want to help us to make the toolkit API/implementation more consistent.
I don't have a build environment, so it is not very serious to send a
patch for the missing services in
UnoControlDialogModel::getAvailableServiceNames() at
toolkit/source/controls/dialogcontrol.cxx 531-562 although I think I've
found the right places to fix.
Nevertheless, I've got the sources (unfortunately, for understanding the
API sometimes I have to go to the implementation), so I'll see if it is
possible to set a build environment during a week-end :-)
There is enough work to do:
- Enhance the GUI documentation
- Update and fix the IDL files for com.sun.star.awt.
- Implement new controls, refactor the toolkit implementation
Implementing new controls is something I'd like to study, I've got my
UNO skill (modestly speaking), but I see that all roads lead to VCL, so
I guess that's something you don't learn in one month or two.
Anyway I've been working in a UNO AWT version of the SvColorDialog
(which I've named ColorPicker) and a ColorTable (like the one in
SvxColorTabPage): my version of the SvColorControl and the
ColorMixingControl are working, what I couldn't get is the ValueSet
look&feel, so a full AWT copy of this won't ever be like the original.
Nevertheless I've seen that wrapping this SvColorDialog won't be
impossible...
Regards
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.ArielConstenlaHaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
