Hi Frank,
Frank Schönheit - Sun Microsystems Germany escribió:
Hi Ariel,
oh yeah! you're right! it works!
Question to Frank: what the hell happens? is this another toolkit issue?
if I remove the image control
[XControlContainer::removeControl(XControl)] *before* creating the
window, the frame, and initializing it with the window: it does not
work. It's like the image control, even removed, invalidates the region
of the new window I create.
I tried also creating the peer after removing the image control, but
didn't work.
My first assumption is have been that though you remove the control, the
model is still present, and perhaps the control is re-created when the
dialog is executed.
However, removing the model plus the control, doesn't change anything.
Okay, next try: Place (in the dialog editor) an arbitrary other control
in the dialog. In the macro, try removing it - either by removing the
control, or by removing the control's model: When the dialog is
executed, the control is still present.
I darkly remember having seen, during some debugging sessions, that a
dialog is re-loaded from its underlying definition when it is executed.
Something like that seems to happen here - whatever you do, the image
control is still present.
Since image controls are not "mouse-transparent", i.e. they consume
mouse clicks, in opposite to group boxes, this is the explanation why
the DSB looks "read-only". In fact it only does not accept mouse clicks
[1]. If you were able to control the "tab stop" property of the window
you created (which the API surprisingly does not seem to allow), then
you would probably be able to tab into the DSB and operate it with the
keyboard.
So, this sounds like at least two issues to me: (1) It's not possible to
programmatically remove controls from a dialog which has been loaded.
(2) It's not possible to control the "tab stop" property when creating a
window via the toolkit.
The first is probably a Basic/Scripting thing, the second an API issue.
Ciao
Frank
[1] The fact that the DSB is painted on top of the image control does
not mean anything: in VCL, when controls overlap, the evaluation order
for painting is exactly the opposite of the evaluation order for
consuming mouse events. That is, the control which is painted at the top
does not get the mouse events, but the control at the bottom.
thanks for the clear explanation. And this explains some "mysteries"
I've found.
The idea of the DSB inside a UNO dialog came to me while investigating
during the weekend how to fix the SDK example I'm working in:
sdk/examples/DevelopersGuide/GUI/DialogDocument.java
This example is supposed to work as a preview window, but it does not:
although loaded read-only, the window gets mouse events (you can select
text, you can right-click, etc.).
I tried to reproduce with XWindow.setEnable(false) the effect you see in
the "File" - "New" - "Templates and documents dialog", and in the Web
Page Wizard dialog, step 5: Style [the preview windows I recall]
In this windows when you try some mouse action you get a beep, as the
XWindow was disabled.
I try to set the window in the SDK example disabled, but getting the
container window from the component loaded inside the dialog and
invoking XWindow::setEnable(false) has no effect at all (while
setVisible(false) yes does: the window can get invisible but not
disabled==no beep on mouse click! a mystery to me)
I think this mystery is solved by your explanation.
Also I came to the ghost-Image control looking how the Web page Wiz.
does it:
in com.sun.star.wizards.web.WebWizardDialog.buildStep5() they insert an
image (imgPreview) as base/parent for the preview window. For this
preview window to be disabled, they set this image control disabled
(property "Enabled" = false) [WebWizardDialog.java 465-467], NOT the
preview window itself [see
com.sun.star.wizards.web.WWD_Startup.addStylePreview()]
This was a mystery until your explanation: if I want to disable the
preview window placed on top of the image control, I have to disable the
parent image control I insert first: it is the bottom control that gets
the mouse events, not the top control.
As a result of this I will correct the SDK example by showing a real
preview window with mouse events disabled, and add the DSB as an example
of showing a full functional component inside a dialog.
Concerning the DSB, now in
http://www.ArielConstenlaHaile.com.ar/ooo/temp/FRAME_CONTROL.odt
there are three versions
DataSourceBrowser_1
DataSourceBrowser_2
DataSourceBrowser_3
they are ordered by "age"
1. create window, frame; use dispatch
2. create window, frame; use XComponentLoader::loadComponentFromURL()
3. simply use the FrameControl
I'd like to hear your suggestions: which one do I include? the more
modern, simpler, FrameControl?
I will also try to get rid of the ghost base control by finding my own
LogicToPixel algorithm (the SDK example uses the unacceptable method of
hard-coding the window pixel PosSize : new Rectangle(40, 50, 420, 550)).
[Extra Toolkit explanation for those not familiar: the FrameControl
-strangely not in the awt module, but in the frame- is one of those that
can not be instantiated by the UnoControlDialogModel's
XMultiServiceFactory, set its model's properties (Height and Width in
MAP), and insert it in the model's container; in fact, it has no model,
it has to be created by the global service manager and added to the
XControlContainer of the dialog (NOT the dialog model's XNameContainer),
and the position and size must be set in pixels, not MAP, using the
control's XWindow::setPosSize() ]
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]
