Hi Noel, >> If you're interested in the cell binding stuff only, > for the moment, but maybe other properties might become interesting also >> ... > 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.
"Don't do it." is the first thing which comes to my mind ... Hmm ... There's a quite some amount of interaction in the form control code between "external" value bindings and "internal" (database) bindings, in that care has to be taken which one should be respected in which situation. Basically, an external binding always supersedes an internal binding. My gut feeling tells me that when the external bindings are separated into toolkit's control models, then it's hard to keep this interaction intact. Well, what probably could and should be done then is overriding the XBindableValue and XListEntrySink interfaces in form's control models, this way disabling (and re-implementing) the complete binding functionality of toolkit's models. Effectively, this probably means large portions of duplicated code - ugly, and a maintenance nightmare. Preventing the code duplication would probably mean re-factoring the form controls so that they don't know their aggregates by UNO interfaces only, but by some implementation pointer - also not really a nice thing. Well, you could introduce some IBindableValue at the toolkit control models, which is obtained (in forms) via XUnoTunnel, and contains all necessary functionality. This might be a viable option. (Note that if you want to go this way, then you should start with the code of dba30d - I made some re-factoring to the code there, which means that now, only the base class - OBoundControlModel - has access to the external value binding member, everything other information is transferred from/to the concrete derived class via virtual methods - this might be a good starting point for a IBindableValue interface.) Also, there's some interaction between value binding and value validation (see css.form.validation). This, however, is less complex, it just says that a value binding is also used as validator, if it supports the required interface. Yet more, the location of the interfaces might be considered ... worth improving. The currently live in css.form.binding - not sure this is a good thing for AWT controls. The cleanest solution would probably be creating interfaces in css.binding, and make the interfaces in css.form.binding dummy-subclasses of the new ones. > 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 Agreed. However, thinking more about it made me think this might not be a big issue. Effectively, when a parent is set at a form control, this parent is checked for certain functionality - if it is not present, nothing should happen. At least tweaking the code to behave this way might not be too difficult. >> 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' ) Yes. With debug=t, you enable OSL assertions (OSL_ENSURE, OSL_ASSERT, OSL_PRECOND, and the like), plus everything which is inside an "#if OSL_DEBUG_LEVEL > 0" block. Non-product builds, enabled with the "dbgutil" switch, contain much more debug information, in particular assertions implemented as DBG_ASSERT, DBG_ERROR, and the like. (And yes, having two different diagnostic systems is ... unfortunate, at least. This is a favourite topic of mine, but consolidating both is an enormous effort.) See http://wiki.services.openoffice.org/wiki/Debug_Levels and http://wiki.services.openoffice.org/wiki/Non_Product_Build. > 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? The entire office. It might or might not work to compile a selected module with this switch - however, chances are good you will encounter a lot of strange breakage at runtime then. >> 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 ) We have - an XML format for form controls - an XML format for UNO dialog controls - an XML format for OOo runtime dialogs (the one implemented by Jan Nieuwenhuizen, IIRC This sounds like at least one format too much. But that might be a different topic. > 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 cellbindinghandler.cxx (extensions/source/propctrlr) is the implementation of the XPropertyHandler which implements all you need. The default implementation of a css.inspection.ObjectInspectorModel, found in defaultforminspection.cxx, declares this handler to be present for form controls only, but not for dialog controls - changing the respective "true" into "false" already instantiates the handler as desired. Which leaves you with the problem that the handler needs a value "ContextDocument" (see CellBindingPropertyHandler::onNewComponent) inside the XComponentContext which was used to create this handler. So, you need to add such a value in the Basic IDE, where you create the ObjectInspector (or PropertyBrowserController, which is a legacy service name for the same component). For an example how to create an XComponentContext which extends a given XComponentContext by additional values, you might want to have a look into OPropertyBrowserController::getPropertyHandlers. Once you have done this, the properties should magically appear at the data tab page - the CellBindingHandler does need nothing except the proper ContextDocument. Ciao Frank -- - 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]
