Hi Frank, On Fri, 2008-06-06 at 23:32 +0200, Frank Schönheit wrote: > Hi Noel, > > please note I answer the mail in dev@dba.openoffice.org, which really is > the more appropriate for this kind of discussion. Please also stick to > this list - doing all this in private communication sounds like a waste > of knowledge to me. Thanks. okay..... > > Just a quick note ( well begging letter perhaps ) to say that I really > > really want to get data-aware controls working for basic dialogs. > > Oh - challenging. :-) hopefully not too challenging > > I did try with some creative harcoding ;-) and met with some success > > ( and some odd behaviour e.g. some hangs etc. but in general it worked ) > > So, I wonder am I on the right or wrong track with this approach? what > > do you think is the right way to go?. What are the obvious pitfalls? > > What I would like to do initially at least is to get the basic dialog to > > use the form control ComboBox, ListBox instead of the standard uncontrol > > ones. > > You don't mention what exactly you did, so I can't answer your question > whether you're on the right track ... basically I created a ( calc ) document with a basic dialog with a ListBox control, in the import code ( xmlscript ) I hardcoded creation of the "com.sun.star.form.component.DatabaseListBox" instead of the normal com.sun.star.awt.UnoControlListBoxModel ( so I saw the code you mentioned regarding trying the global multiservicefactory if the dialog factory failed ). I had some other test code that used the basic dialog and in that code I hardcoded values for the model properties 'ValueBinding' and 'ListEntrySource'. As I said it seemed more or less to work. The ListBox is populated with the values in the range I specified, selecting entries in the ListBox changed the value in the bound cell, so at least that is promising > > The major problem I anticipate is that the form control models are not > prepared to live in a container which is *no* data aware form. This > might or might not be a problem ... > First, IIRC the dialog model does *not* set itself as parent of its > control models - does it? If it *does*, then any access in the form > control models to their parent component must be checked, as it is > potentially problematic. I think you recall correctly, at least the standard unocontrol models ( in toolkit ) don't offer a XChild interface, so although I can't say for certain that the Dialog code tries to set itself as parent I would think it is unlikely ( I will look later to confirm ). > If the dialog model does *not' set itself as parent, then the form > controls might in fact work in the dialog, but without the > database-related functionality. > > If you're interested in the cell binding stuff only, for the moment, but maybe other properties might become interesting also > this might be > sufficient. The cell binding implementations are much more modern than > the database bindings, so I have hope here. In particular, cell bindings > are a special case of "value bindings" (see the css.form.binding > module), which are to be implemented external to the form control > models, and have a very precise interface to those models. > At the opposite, database bindings are implemented inside the form > control models, and parts of the functionality is taken from the data > forms, which thus are expected to be the parent of a form control model. > Though some refactoring over the years improved the situation here, > that's still a mess in some parts. I guess what I was trying to tease out in my clumsy way is, do you think it worth moving the 'value binding' bits out forms to the 'base' control model in toolkit. I worry about the form control bindings you mention and whether they could cause grief ( I did say in the last mail that I did notice some hangs, particularly when using the Xray tool to introspect the control model ) I didn't really investigate more at this stage. The parent issue also concerns me, ok, I think at the moment there isn't a problem because I suspect the Dialog doesn't set itself as a parent. But I would hope there is a future when the Dialog code is more containment aware and would set itself as parent > > > Another item on your list should be the property browser, implemented as > css.inspection.ObjectInspector in extensions/source/propctrlr some useful info there indeed, I will of course take note. > In any case, I *strongly* recommend you doing your implementations in a > non-product build (configure switch --enable-dbgutil), the code is paved > with assertions which in a non-product build will report you when > something is not as expected. does this give you something extra than just building with debug? ( e.g. 'build debug=t' ) or is this just necessary for windows builds? Does one need to build the entire office with this switch ( e.g. from the configure ) or is it possible to be a bit more selective? > > > > of course there are additional things to think about like > > a) backward compatibility, e.g. would a form control ListBox populated > > with the properties of the more basic unocontrol ListBox behave the same > > way > > It should - however, only detailed tests will tell you :) indeed, of course if pushing 'ValueBinding' & 'ListEntrySource' to the unocontrol ( in toolkit ) is an option then indeed the behaviour should be the same I think ( but yes, only testing will tell ) > > c) file format changes ( although iirc the dialog format is not part > > of odf so should be a little more flexible ) > > Don't know about this. Isn't a colleague of you implementing the layout > manager, and had to deal with dialog/control file format issues, too? I think that is dialog as in dialog descriptions in the build, but I will find out for sure > In > general, whatever we do to the formats, I would appreciate consolidating > all formats into one. Not sure what you mean, or do you just mean the names etc. should be the same for the odf and basic dialog ( I think currently they are different ) > > > d) how the new properties should be presented ( reproduce the data > > tab ) - what happens to the form properties, should these be suppressed > > ( I must admit to being clueless about the forms ) > > See above - as said, the implementation for the property browser is in > extensions/source/propctrlr. To understand how it works, I refer you to > the module css.inspection, it should give you a good overview. Again, if > you go for cell bindings only, then you just need to ensure that the > CellBindingHandler is used when inspecting a "new" dialog control - > which might even happen automatically It didn't, for form controls these are usually displayed in a separate 'Data' Tab, I suppose I need to look and see how/where that's done, that said I wouldn't loose any sleep over it at the moment [...] > > HTH so far. For concrete questions, I'm reading [EMAIL PROTECTED] ... yes, helpful indeed :-)
Thanks, Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
