Hi Noel,
>> 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 )
Yes.
>> 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 )
What I would not like to do is implementing the same thing in two modules.
However, imagine we have something like
class SAL_NO_VTABLE IBindableValue
{
public:
virtual Sequence< Type > getSupportedBindingTypes() const = 0;
virtual Any convertControlValueToBindableValue(
const Any& _rControlValue ) const = 0;
virtual Any convertBindableValueToControlValue(
const Any& _rBindableValue ) const = 0;
...
};
I.e., an interface which hides *all* things which are specific to a
control type. Then, a central (and probably small) implementation in
UnoControlModel could use such an interface (probably implemented by the
derived models) and this way implement XBindableValue, and the transfer
of the actual bound value from/to the control model.
In forms, we would need a way to retrieve an IBindableValue from a
concrete UNO control model (which is implemented as toolkit-level
control, but only known by UNO interface) - this could even be
XUnoTunnel ...
The OBoundComponent then could use this interface to knit the bindable
value to the control model, and in particular (and additionally to what
the UnoControlModel does) care for interdependencies between the value
binding and the database binding.
This way, we could probably implement large parts of the code only once
i.e. the different (per control type) implementations of IBindableValue.
If the code using the IBindableValue is more complex than I currently
think, even this might be outsourced into a helper class, saving even
more code duplication.
What I wanted to say with my comment about CWS dba30d is that in this
CWS, I re-factored the handling of the value bindings, so that the base
class (OBoundComponent) does all the administrative stuff, and just
calls some virtual methods which need to be implemented by derived
classes. The set of those virtual methods could perhaps be a good
starting point for designing IBindableValue.
> 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.
I agree that model substitution is most probably significantly easier.
Though the other approach is "nicer" with respect to its architecture,
it doesn't bring much other gain.
For the deadlocks: Again, let me recommend you the CWS dba30d
(respectively a master milestone where it is integrated): The reasoning
for the aforementioned re-factoring was that Calc's cell binding
implementations insists on locking the solar mutex (indirectly, in
reality the Cell implementations do), which is absolutely deadly when
called from a non-main thread with another mutex locked. So, I
overhauled the OBoundComponent implementation so that every call into
the external binding is guaranteed to have no own mutex locked - perhaps
this helps in your scenario, too.
Ciao
Frank
PS: I'm on vacation starting tomorrow, 'til end of June, so don't expect
any quick answers the next 10 days ...
--
- 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]
