List Info

Thread: Re: Accessing a dialog from the frame hierarchy




Re: Accessing a dialog from the frame hierarchy
user name
2007-10-11 05:53:12
Paolo Mantovani napisaƂ(a):

>> First I create and display the dialog in one macro
-- pretty standard
>> stuff except that I pass the current frame's
container window as the peer:
>>
>> smgr =
XSCRIPTCONTEXT.getComponentContext().ServiceManager
>> ctx = XSCRIPTCONTEXT.getComponentContext()
>> dialogModel = smgr.createInstanceWithContext(
>>              
"com.sun.star.awt.UnoControlDialogModel", ctx)
>> dialogModel.Title = "FooBar"
>> controlContainer = smgr.createInstanceWithContext(
>>                   
"com.sun.star.awt.UnoControlDialog", ctx)
>> controlContainer.setModel(dialogModel)
>> toolkit = smgr.createInstanceWithContext(
>>           "com.sun.star.awt.Toolkit",
ctx)
>> containerWin =
XSCRIPTCONTEXT.getDocument().getCurrentController()
>>                .getFrame().getContainerWindow()
>> controlContainer.createPeer(toolkit, containerWin)
>> controlContainer.setVisible(True)
> 
> This is the old way, when men were men and created
their own AWT-Windows 
> Apart from jokes, is there any reasons for not using
the (relatively) new 
> css.awt.DialogProvider ?
> In this way you could design the dialog in the
Starbasic IDE and then recall 
> it from anywhere.

Yes, I rather prefer the manly way -- visual IDEs are for
wimps 
Actually, I made an initial design decision to create all
the dialogs
for my app from code exclusively, so I could contain
everything in a
single file to ease distribution and installation later on.
Looking back
I'm not so sure it was the best choice, but it works so far,
so I'm
sticking with it  That
aside, it seems to me that my problem of
accessing an open dialog would still apply, regardless of
whether the
dialog was created in code or instantiated from a ready
model using the
DialogProvider.

> Perhaps I can propose an idea for a workaround, see
below:
--- 8< ---
> As you can see, the dialog is now attached to a frame
that belongs to the 
> frames hierarchy.
> In this way you can access to your dialog from anywhere
in (more or less) this 
> way:
> 
> (Basic example - adapt to your context)
> ----------------------------------------------------
> oMyFrame =
StarDesktop.findFrame("MyOwnFrame", _
>  com.sun.star.frame.FrameSearchFlag.GLOBAL)
> oDialog = oMyFrame.ComponentWindow
> ----------------------------------------------------

Paolo, you're the best  This is
exactly what I needed - just had to
find someone with a better understanding of the whole UI
structure than
myself, and who better than you. Thanks a million!

>> And if not, what could I do 
>> to get a similar effect (maybe abandon dialogs and
create a window some
>> other way)? 
> 
> Of course you can use a TopWindow instead of an
UnoDialog this would give you 
> more flexibility but at the cost of some more code
lines, especially for the 
> UnoControls management

That's why I was reluctant to let go of the UnoDialog-based
approach --
it's convenient and pretty intuitive to work with, as it is
basically
similar to other GUI frameworks I've used previously (Swing,
wxWidgets etc.)

Thanks for your help, Paolo, this will have me well on my
way 

Cheers,

Zbigniew Banach

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


[1]

about | contact  Other archives ( Real Estate discussion Medical topics )