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.
(extensive quoting for new readers) > 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. > So the good news is that I am willing to do some work, the bad news is I > really need advice, pointers etc. ( and am hoping you might help ) > > I had a look at the complicated ( or complicated for me at any rate ) > code involved around toolkit, forms etc. to try and get some handle of > whats available, or at least how it at a high level hangs together. I > tried to start on this journey of discovery ( or pain ) by attempting to > get a ListBox control on a basic Dialog to work. > > Basically the standard ListBox/ComboxBox controls offer pretty limited > functionality and the form control one(s) seems much closer ( especially > from an interoperability pov ) to what I would expect . Specifically I > am interested in enabling the List box to on a Dialog to be for example > populated with a cell range and set up a linked cell for the selected > value. > > Dialogs use the unocontrols ( from toolkit ) though at least the form > model OListBoxModel aggregates the unocontrol model via > OBoundControlModel, additionally the form control OListBoxControl > aggregates the control via OBoundControl. So... I suspect the the form > control and unocontol are interchangeable in a basic Dialog ( or are > they? ) Kind of. In general, placing a list box (or any other form-level) control model in a Basic dialog should be a matter of using the dialog's createInstance method. Years ago, I extended this method to not only accept a list of fixed names, but if it encounters an unknown service name, it instantiates the respective at the global service manager, and uses that one provided it claims to support the css.awt.UnoControlModel service. Note that the route via the dialog's createInstance is strictly necessary, as the dialog wraps all its child components into a class (see geometrycontrolmodel.* in toolkit) which adds some properties to it. Historically, those were X, Y, Width, Height, IIRC nowadays it's also Name, at least. Note that this Name might be one pitfall, the form control models have a Name themself, I am unsure which problems might be caused by "overriding" this property from the outside. In general, any access in the "inner" class, i.e. the form control models, to such a property might lead to undesired results, if not done properly. > 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 ... 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. 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, 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. Another item on your list should be the property browser, implemented as css.inspection.ObjectInspector in extensions/source/propctrlr. Parts of it are stone-aged, which explains why there are some hacky differentiations between "inspecting a form control" and "inspecting a dialog control". Those might need to be adjusted. In particular, the big table in formmetadata.cxx, which controls which properties are available for which situation, need to be adjusted. IIRC, the FormComponentHandler also has a member telling whether it inspects a form or a dialog control currently, whose usage needs to be carefully examined. Of course, persistency might be an issue, if you want to save the new control types. 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. > 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 :) > b) related to the above should we present 2 different controls in > control toolbox ( the old & new ) This depends on the overall picture of your feature, I'd say. Personally, I'd say if you just go for the cell bindings, then having one control might be sufficient - it's just that if the user edits a dialog embedded in a spreadsheet document, then there would be the additional properties. > 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? In general, whatever we do to the formats, I would appreciate consolidating all formats into one. > 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, I think there is a mechanism in place which examines the to-be-inspected component, and decides which handlers should be used. If a "bindable" control in a spreadsheet document is encountered, then the CellBindingHandler is used. You just need to tune the definition of "control in a spreadsheet document" - it also needs to recognize contols in a spreadsheet-embedded dialog, too. > Any thoughts? > > ps I am interested in providing this functionally as part of trying to > support import of VBA Userforms HTH so far. For concrete questions, I'm reading [EMAIL PROTECTED] ... Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
