Hi Frank On Sat, 2008-06-14 at 23:47 +0200, Frank Schönheit - Sun Microsystems Germany wrote: > 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. > "Don't do it." is the first thing which comes to my mind ... Hmm ... hah :-) >
> 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. I presume you mean in the case where the XBindableValue & XListEntrySink interfaces exist at the toolkit control ( assuming they have been moved there of course ) Sorry if I appear to be asking what you already have explained but it is just make sure I really actually understand what you have explained ( please bear with my ignorance ) > 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. ok, agreed we definitely do not need more code duplication > > 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. Do you mean some sort of a common c++ ( non-uno ) implementation to be shared by the toolkit and forms models? ( if so I thought you rejected that idea above e.g. the '...also not really a nice thing', or you are rethinking this idea in-line ) > > (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.) I'm not entirely sure that I understand exactly what you mean ( see IBindableValue query above ) > > 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. right > 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. I think you are right, it shouldn't be too hard ( and should check anyway ) > > > >> In any case, I *strongly* recommend you doing your implementations > in a > >> non-product build (configure switch --enable-dbgutil), > > See http://wiki.services.openoffice.org/wiki/Debug_Levels and > http://wiki.services.openoffice.org/wiki/Non_Product_Build. those links are very informative ( I will do a build with this enabled for sure ) > 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. perhaps, but for me already there is already much to think about, from the implementation pov I don't care at all about the xml format ( don't get me wrong I do care about the format but just not right now ;-) ) > > > 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. ;-) interesting, again lots of good info, thanks. Also perhaps I shouldn't give up on the orig idea of just substituting the Models ( it would seem to be the easier solution ), but for that I must have a look at these hangs and see why this is happening. Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
