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. -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
