On Thu, Apr 18, 2013 at 03:54:19PM +0100, Michael Meeks wrote: > * Scripting interface for form elements broken (?) (Lionel)
> + I've just sent a message to the dev ML with subject > "Value of a ListBox, FMC paradigm for Form elements (controls)" > + C++ module / forms / frm:: > + not only used by 'base' > In short: > 1) our scripting (UNO) interface to form elements (controls) > sucks. It exposes the models, but the models don't have a > getCurrentController() and the control(ler) exposes useful APIs > that are thus NOT REACHABLE. > + getView returns the same object as the controller > AI: + get a second view on what's up (Stephan) As explained in the other thread, there is a somewhat roundabout way to get the view/controller when one has the model, so it is not as bad as I said, and is workable. > 2) ListBox has the wrong notion of "current value". Change it to > the right one incompatibly? Add a new "current *bound* value" > notion to stay compatible, but make the interesting thing > accessible in some way? > + has two lists of key/values pairs. > + with a one-to-one mapping between the two, > + values that are displayed; and another that is written. > + getCurrentValue - shouldn't return string displayed, > but the value > + on a date-field; don't get Mon/1st/Jan - but an abstract date. > + not so clear as all that (Norbert/Eike) > + value written to field, not exposed at all (Lionel) > + API is a special exception for this box > + been there for a while. > + keeping back-compat there is important (Eike) > + introduce a new method - getActualCurrentValue > + or incompatibly extend the existing interface > + can we put it in a property instead ? As I wrote on the other thread, getCurrentValue is part of the interface meant to be used by validators. http://api.libreoffice.org/docs/common/ref/com/sun/star/form/validation/XValidatableFormComponent.html That is, a procedure that, given a value for the control says one of: - yes, accept that value (and eventually write it to the database) - no, reject that value with this error message (and force the user to change it or cancel his/her changes) To me, it is craziness that the validator is supposed to operate on a different value than what will be written out, so I changed it over Norbert & Eike's objections. If having read this email the ESC still disagrees with me, we'll see what we can do (in terms of implementation, to revert only that change without breaking the other improvements I did). I *also* added new properties SelectedValue and SelectedValues to access the values of the selected entries. I updated the "External Value Binding" mechanism for ListBox http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/External_Value_Suppliers http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Value_Bindings It is a mechanism that is supposed to generalise the concept of linking controls to database data; they are linked to an arbitrary data supplier / sink through an UNO interface. I could do this in a mostly backwards compatible way, because it was already the case that what the external value binding gets depends on the type it supports... The values are served as another type (namely Any) than indices or display strings. Note that it was already the case that when an external value binding installs itself as validator, the value passed to the validator was tweaked to match what was served to the external value binding. In support of my position "the validator should get the same value as what is written out". -- Lionel _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
