Opening a GridControl in a UNO Dialog

[Fernand Vanrie]

Hallo all,

Thanks to what i learned from Frank and Ariel i can open a
DataSourceBrowser in a UNO Dialog doing the same for a FormGridView
fails in a way that the FormGridView opens in the dialog but without data ?

Wath I am doing is loading a ".component:DB/FormGridView" in a UNO
Dialog ControlFrame using the same mediadescriptor (LoaderArguments) as
for the DataSource Browser, wath are I missing??

the code based on the work of Ariel Constenla-Haile

Sub DataSourceBrowser_FrameControl
 
    Dim oDlg as Object, oGhost as Object, oFrameControl as Object
    Dim aPosSize
    Dim oFrame as Object, oController as Object, oModel as Object
   
    DialogLibraries.loadLibrary("Standard")
       
    oDlg =
createUnoDialog(DialogLibraries.Standard.DBTABLEPREVIEWDIALOG) ' dialog
with a Frame_control init namend  "WIN_BEAMER
       
    oGhost = oDlg.getControl("WIN_BEAMER")
    aPosSize = oGhost.getPosSize()
   
    oFrameControl = createUnoService("com.sun.star.frame.FrameControl")

    oDlg.addControl("FRAME_CTRL", oFrameControl)
    oFrameControl.setPosSize(aPosSize.X, aPosSize.Y, aPosSize.Width,
aPosSize.Height, _
                                com.sun.star.awt.PosSize.POSSIZE)
   
    Dim aLoaderArguments(5) as New com.sun.star.beans.PropertyValue
    aLoaderArguments(0).Name = "DataSourceName"
    aLoaderArguments(0).Value = "MyRegisteredDatabase"
    aLoaderArguments(1).Name = "CommandType"
    aLoaderArguments(1).Value = com.sun.star.sdb.CommandType.TABLE
    aLoaderArguments(2).Name = "Command"
    aLoaderArguments(2).Value = "My_table"
       
    aLoaderArguments(3).Name = "ShowTreeView"
    aLoaderArguments(3).Value = FALSE
    aLoaderArguments(4).Name = "ShowTreeViewButton"
    aLoaderArguments(4).Value = FALSE
    aLoaderArguments(5).Name = "ShowMenu"
    aLoaderArguments(5).Value = FALSE
       
    'This property is not documented in the IDL
   
'http://api.openoffice.org/docs/common/ref/com/sun/star/frame/FrameControl.html
    oFrameControl.LoaderArguments = aLoaderArguments
   
'    oFrameControl.ComponentUrl = ".component:DB/DataSourceBrowser"
oFrameControl.ComponentUrl = ".component:DB/FormGridView"
    oFrame = oFrameControl.Frame
    If NOT IsNull(oFrame) Then
        oController = oFrame.Controller
        If NOT IsNull(oController) Then
            oModel = oController.Model
            If NOT IsNull(oModel) Then'here is NULL: the DSB has no model
                '...
            End If
        End If
    End If
 
End Sub

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Fernand,

> Thanks to what i learned from Frank and Ariel i can open a
> DataSourceBrowser in a UNO Dialog doing the same for a FormGridView
> fails in a way that the FormGridView opens in the dialog but without data ?

The FormGridView is meant as "slave" view for an existing and living
form, it's the component you see when pressing the "Form as Table"
button in a form document. So, it won't work on its own.

I don't know out of my head how you would need to create a proper env
for the FormGridView, but can we go one step back, and you explain what
you want to achieve? Depending on this, the FormGridView might not be
the best choice.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Fernand Vanrie]

Frank ,
For months i am looking for the best solutions to manipulating data in
Dialogs instead of forms. So i was missing a GridControl.
Last week i Readed on Gulfoss that a new AWT UNO Dialog GridControl is
coming, I discused with the makers why there is no "dataloader"
available.  They told me that this GridControl is a "developer" tool and
we have to build our proper Loading stuff..... I can do that  but it wil
be terible slow using loops over the resultset.....
Then i stumbled on 2008- discussion between you and Ariel about  
implementing  a DataSourceBrowser in a Uno Dialog. This solution is not
only faster but also available NOW Then I was just wondering if we also
can use this FormGridView in the same way.
Thanks to your knowledge its now (again) all clair for me  :-).

As Always

Thanks

Fernand

>
>  
>> Thanks to what i learned from Frank and Ariel i can open a
>> DataSourceBrowser in a UNO Dialog doing the same for a FormGridView
>> fails in a way that the FormGridView opens in the dialog but without data ?
>>    
>
> The FormGridView is meant as "slave" view for an existing and living
> form, it's the component you see when pressing the "Form as Table"
> button in a form document. So, it won't work on its own.
>
> I don't know out of my head how you would need to create a proper env
> for the FormGridView, but can we go one step back, and you explain what
> you want to achieve? Depending on this, the FormGridView might not be
> the best choice.
>
> Ciao
> Frank
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Fernand,

> For months i am looking for the best solutions to manipulating data in
> Dialogs instead of forms.

Just this morning, sitting in the subway and having no newspaper to read
:), I wondered whether it would make sense to implement the runtime code
for all the database controls in dialogs. Adding a full-blown dedicated
UI for creating "database dialogs" would be an additional effort, but
perhaps it would be valueable having only the "runtime", i.e. the
ability to programmatically create and execute such dialogs. As a first
step, at least.

> So i was missing a GridControl.
> Last week i Readed on Gulfoss that a new AWT UNO Dialog GridControl is
> coming, I discused with the makers why there is no "dataloader"
> available.  They told me that this GridControl is a "developer" tool and
> we have to build our proper Loading stuff..... I can do that  but it wil
> be terible slow using loops over the resultset.....

Not olnly that, it won't scale. IIRC, the API for the new table control
requires you to have all data in memory, something you usually won't do
with a complete result set. Instead, there you usually only hold the
data which is displayed (plus some cached data), and re-fetch everything
else as needed.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Noel Power-2]

Hi Frank,
On Tue, 2009-10-06 at 09:45 +0200, Frank Schoenheit, Sun Microsystems
Germany wrote:

> Hi Fernand,
>
> > For months i am looking for the best solutions to manipulating data in
> > Dialogs instead of forms.
>
> Just this morning, sitting in the subway and having no newspaper to read
> :), I wondered whether it would make sense to implement the runtime code
> for all the database controls in dialogs. Adding a full-blown dedicated
> UI for creating "database dialogs" would be an additional effort, but
> perhaps it would be valueable having only the "runtime", i.e. the
> ability to programmatically create and execute such dialogs. As a first
> step, at least.

This sounds a little familiar to something we discussed on this list in
the past ( it wasn't exactly the same thing, but if you remember we
talked about using form control models ( especially data aware ones )
with the toolkit controls in dialogs ) as such, I think supporting
database controls is a great idea :-)  
Btw I use currently use the form control models with the toolkit
controls ( and it seems to work well ) in ooo-build, the (self imposed)
limitation is that this is only available 'transiently' when importing
MSO 'Userform' controls. Not sure if any of the work I have done is that
useful in this case but I'd happily attach it/upload [*] etc. somewhere
should you want it or think it's useful. In anycase I am interested in
upstreaming this code anyway but I was thinking about doing that in the
context of a future vba support CWS.
However, as I said at the moment it really isn't suitable to be used
with Openoffice directly ( lack of ui/persistence support for one ) and
I haven't had the time to concentrate on that part of it :-/ It sounds
though that any work in this area would be relevant to ( and affect ) a
'proper' solution for what I would like to do, so I am very interested

Noel

[*] currently I don't recall exactly what I have in terms of changes but
iirc it's just a cheap and nasty solution to use the appropriate (form)
models when the dialog is in vba mode


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Fernand Vanrie]

Noel ,

Any change your code can been used in Basic ?

Greetz
Fernand

> Hi Frank,
> On Tue, 2009-10-06 at 09:45 +0200, Frank Schoenheit, Sun Microsystems
> Germany wrote:
>  
>> Hi Fernand,
>>
>>    
>>> For months i am looking for the best solutions to manipulating data in
>>> Dialogs instead of forms.
>>>      
>> Just this morning, sitting in the subway and having no newspaper to read
>> :), I wondered whether it would make sense to implement the runtime code
>> for all the database controls in dialogs. Adding a full-blown dedicated
>> UI for creating "database dialogs" would be an additional effort, but
>> perhaps it would be valueable having only the "runtime", i.e. the
>> ability to programmatically create and execute such dialogs. As a first
>> step, at least.
>>    
> This sounds a little familiar to something we discussed on this list in
> the past ( it wasn't exactly the same thing, but if you remember we
> talked about using form control models ( especially data aware ones )
> with the toolkit controls in dialogs ) as such, I think supporting
> database controls is a great idea :-)  
> Btw I use currently use the form control models with the toolkit
> controls ( and it seems to work well ) in ooo-build, the (self imposed)
> limitation is that this is only available 'transiently' when importing
> MSO 'Userform' controls. Not sure if any of the work I have done is that
> useful in this case but I'd happily attach it/upload [*] etc. somewhere
> should you want it or think it's useful. In anycase I am interested in
> upstreaming this code anyway but I was thinking about doing that in the
> context of a future vba support CWS.
> However, as I said at the moment it really isn't suitable to be used
> with Openoffice directly ( lack of ui/persistence support for one ) and
> I haven't had the time to concentrate on that part of it :-/ It sounds
> though that any work in this area would be relevant to ( and affect ) a
> 'proper' solution for what I would like to do, so I am very interested
>
> Noel
>
> [*] currently I don't recall exactly what I have in terms of changes but
> iirc it's just a cheap and nasty solution to use the appropriate (form)
> models when the dialog is in vba mode
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Noel,

> This sounds a little familiar to something we discussed on this list in
> the past ( it wasn't exactly the same thing, but if you remember we
> talked about using form control models ( especially data aware ones )
> with the toolkit controls in dialogs ) as such

I darkly remember, now that you mention it ...

> Btw I use currently use the form control models with the toolkit
> controls ( and it seems to work well ) in ooo-build, the (self imposed)
> limitation is that this is only available 'transiently' when importing
> MSO 'Userform' controls. Not sure if any of the work I have done is that
> useful in this case but I'd happily attach it/upload [*] etc. somewhere
> should you want it or think it's useful.

Sure, im always interested in seeing what you're doing to ¨my¨ form
controls :)

> In anycase I am interested in
> upstreaming this code anyway but I was thinking about doing that in the
> context of a future vba support CWS.

Any concrete time line for this?

> However, as I said at the moment it really isn't suitable to be used
> with Openoffice directly ( lack of ui/persistence support for one ) and
> I haven't had the time to concentrate on that part of it :-/ It sounds
> though that any work in this area would be relevant to ( and affect ) a
> 'proper' solution for what I would like to do, so I am very interested

I think having a solution without UI and persistence is a great first
step, I'd be willing to get this into MWS in such a shape (and add some
test cases to ensure it doesn't break, and then officially declare it as
feature).

So, when you upstream this, I'd be more than happy to have a look at it.

Ciao
Frank
--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Noel Power-2]

Hi Fernand,
On Tue, 2009-10-06 at 12:04 +0200, Fernand Vanrie wrote:
> Noel ,
>
> Any change your code can been used in Basic ?
well, it depends what you mean by my code, iirc ( and it's been quite a
while since I looked at this ) the code I have in the ooo-build filter
substitues the form control model when building the imported dialog
( this is sure to be done by the existing uno api and hence should be
achievable by basic ) I am not sure if doing this out of the box will
work in the vanilla build, but, I see no reason why it shouldn't. Also
you would need to do all of this programatically, e.g. create the Dialog
and add the required controls/models[1], position them, set the
appropriate attributes etc. all manually. In theory it *should* work.
Anyway it's worth a try I guess ( I will look back my code when I get a
chance )

hth
Noel

[1] e.g for a data-aware listbox call insertByName on the dialog model
and insert a control created from "com.sun.star.form.component.ListBox"
specifier instead of "com.sun.star.awt.UnoControlListBoxModel"

>
> Greetz
> Fernand
> > Hi Frank,
> > On Tue, 2009-10-06 at 09:45 +0200, Frank Schoenheit, Sun Microsystems
> > Germany wrote:
> >  
> >> Hi Fernand,
> >>
> >>    
> >>> For months i am looking for the best solutions to manipulating data in
> >>> Dialogs instead of forms.
> >>>      
> >> Just this morning, sitting in the subway and having no newspaper to read
> >> :), I wondered whether it would make sense to implement the runtime code
> >> for all the database controls in dialogs. Adding a full-blown dedicated
> >> UI for creating "database dialogs" would be an additional effort, but
> >> perhaps it would be valueable having only the "runtime", i.e. the
> >> ability to programmatically create and execute such dialogs. As a first
> >> step, at least.
> >>    
> > This sounds a little familiar to something we discussed on this list in
> > the past ( it wasn't exactly the same thing, but if you remember we
> > talked about using form control models ( especially data aware ones )
> > with the toolkit controls in dialogs ) as such, I think supporting
> > database controls is a great idea :-)  
> > Btw I use currently use the form control models with the toolkit
> > controls ( and it seems to work well ) in ooo-build, the (self imposed)
> > limitation is that this is only available 'transiently' when importing
> > MSO 'Userform' controls. Not sure if any of the work I have done is that
> > useful in this case but I'd happily attach it/upload [*] etc. somewhere
> > should you want it or think it's useful. In anycase I am interested in
> > upstreaming this code anyway but I was thinking about doing that in the
> > context of a future vba support CWS.
> > However, as I said at the moment it really isn't suitable to be used
> > with Openoffice directly ( lack of ui/persistence support for one ) and
> > I haven't had the time to concentrate on that part of it :-/ It sounds
> > though that any work in this area would be relevant to ( and affect ) a
> > 'proper' solution for what I would like to do, so I am very interested
> >
> > Noel
> >
> > [*] currently I don't recall exactly what I have in terms of changes but
> > iirc it's just a cheap and nasty solution to use the appropriate (form)
> > models when the dialog is in vba mode
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >  
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Noel Power-2]

Hi Frank,
On Wed, 2009-10-07 at 09:19 +0200, Frank Schoenheit, Sun Microsystems
Germany wrote:
> Hi Noel,
>
> Sure, im always interested in seeing what you're doing to ¨my¨ form
> controls :)
:->>
>
> > In anycase I am interested in
> > upstreaming this code anyway but I was thinking about doing that in the
> > context of a future vba support CWS.
>
> Any concrete time line for this?
:-/ as soon as I can, there is a cws ( npower12 ) in the pipeline and it
needs to be integrated before I can start on the next one. That doesn't
mean that for form control stuff depends on this cws but rather how I
use it ;-)

>
> > However, as I said at the moment it really isn't suitable to be used
> > with Openoffice directly ( lack of ui/persistence support for one ) and
> > I haven't had the time to concentrate on that part of it :-/ It sounds
> > though that any work in this area would be relevant to ( and affect ) a
> > 'proper' solution for what I would like to do, so I am very interested
>
> I think having a solution without UI and persistence is a great first
> step, I'd be willing to get this into MWS in such a shape (and add some
> test cases to ensure it doesn't break, and then officially declare it as
> feature).

hmm, looks like I lied, there is persistence of sorts, e.g. going from
the filter to the dialog it seems the state of the dialog is transferred
via the dialog stream so it looks like that I have already introduced
some 'unofficial' attributes to support this, but like I said, I am not
happy to upstream the current scheme and it is not usable in the broader
openoffice generic sense. This is the part would to be ironed out as
part of upstreaming, I would be happy with your input/help on that.
But, like I said the dependency on another cws here is artificial ( its
more to do with fitting in with my ( somewhat dynamic ) schedule ) So,
bearing in mind that, I will try and find some time to dabble with this
prior to working on this in a more general vba cws. Really I think all
that is necessary is to nail down the right ( and most flexible ) way to
express using the different controls in the dialog xml, that would seem
to point to using the service name itself in as an attribute of the
control, this would fit very well because in the basket-case task (VBA)
there may be a need in the future to subclass the existing controls to
provide different behaviour. The data-awareness attributes afaik I
copied already from form controls and that should be ok. It would be
great to separate this from UI and I am happy you don't see a problem
with that. Maybe I just will create cws for this anyway, as always the
problem is bloody time :-( ( not to create the cws but to work on it )
Anyway lets see how it goes

Thanks,
Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Noel,

> hmm, looks like I lied, there is persistence of sorts, e.g. going from
> the filter to the dialog it seems the state of the dialog is transferred
> via the dialog stream so it looks like that I have already introduced
> some 'unofficial' attributes to support this,

Ouch. extending the ODF file format - and I think that the dialog
descriptions are part of ODF, too - is asking for trouble. Well, for a
lot of work, at least :-\

> but like I said, I am not
> happy to upstream the current scheme and it is not usable in the broader
> openoffice generic sense. This is the part would to be ironed out as
> part of upstreaming, I would be happy with your input/help on that.

Sure, let's see how far we can get there.

Thanks & Ciao
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Noel Power-2]

Hi Frank
On Wed, 2009-10-07 at 11:12 +0200, Frank Schönheit wrote:

> Ouch. extending the ODF file format - and I think that the dialog
> descriptions are part of ODF, too - is asking for trouble. Well, for a
> lot of work, at least :-\
ouch is right, I was depending on the fact that dialog.xml was not part
of odf ( it used not to be ) /me gets a sinking feeling. Ok, maybe
Andreas knows ( I'll ask him )

Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Noel Power-2]

Hi Frank,
On Wed, 2009-10-07 at 10:23 +0100, Noel Power wrote:
> Andreas knows ( I'll ask him )
confirmation received, neither the dialog or basic streams are ODF ( /me
phews a sigh of relief )
Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Frank Schoenheit, Sun Microsystems Germany]

Hi Noel,

>> Andreas knows ( I'll ask him )
> confirmation received, neither the dialog or basic streams are ODF ( /me
> phews a sigh of relief )

/me too :)

Ciao
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...