Value of a ListBox, FMC paradigm for Form elements (controls)

Context: (Data)Forms and their elements (controls). I'm most
interested in Base, but these things are also used in other
LibreOffice apps I presume? (At least when we import an excel document
that has some... Plus I presume our Calc has the same feature
"natively".)

A ListBox is a form element (or "form control") that takes:

1) a list of values (hardcoded in its properties or from a
   table/query...) to be displayed

2) lets the user choose one (or several) of them

3) *usually* / often, a *second* list of values, same length as
   display list, that gives the *value* corresponding to the choices
   made by the user.

   (one can have the degenerate case where the two lists are the same)

To me, this is like:

 The value of a FormattedDate control is not the string "June 3rd,
 2005", but the "abstract" date (Year=2005, Month=6, Day=3). "June
 3rd, 2005" is merely the *display* format.

The same applies to ListBox: it makes a correspondence between "actual
values" (or "storage value") and "display values". It shows the
display values to the user, but (when bound to a database field)
stores / reads the *actual* value.


PROBLEM 1: value of a ListBox
=============================

Currently, the "CurrentValue" pseudo-property (getCurrentValue()
method) of a ListBox returns the current *display* value, not the
*storage* value. To me, this is a bug or (serious) misdesign. More
generally, the *storage* values are *not* exposed at all by the UNO
API. IMO this needs to change.

I have a patch ready to change it, but... incompatible behaviour
change... Basically, my question to you is: what should I do? Just
change it, or introduce a new getCurrentBoundValue() to disambiguate,
and leave getCurrentValue() alone?


Even if I change getCurrentValue(), I'd still like to add access to an
*arbitrary* storage value (that is not necessarily to currently
selected one), like the UNO API already exposes access to an arbitrary
display value. Which leads me to:


PROBLEM 2: Frame-Controller-Model paradigm as applied to Form elements
======================================================================

Frame elements seem to have a b0rken implementation of the
Frame-Controller-Model paradigm.

When I bind a macro to an event of a ListBox, Event.Source is a
frm::OListBoxControl (see forms/source/component/ListBox.hxx). So far,
so good.

It has a getView() that returns... itself. Hu?

It has a getModel() that returns a frm::OListBoxModel. That in itself
makes sense, *but*:

1) frm::OListBoxModel has no method/API to get back the corresponding
   frm::OListBoxControl

2) The interface com::sun::star::awt::XListBox is exposed by the
   OListBoxControl, not the OListBoxModel.

Now, imagine instead of binding a macro to an event of the ListBox, I
bind to an event of a Button of the same form. Makes sense, when the
user pushes the "OK" button, my macro goes read the ListBox value and
does some processing or when the user types the "refresh listbox"
button the macro goes and adds/removes values from the lists.

So, Event.source is a frm::OButtonControl. I call
getModel().getParent().getParent() (enough getParent() calls to get
the ODatabaseForm), then I do getByName("name_of_listbox_element"),
and I get... a frm::OListBoxModel. With no way to get the
OListBoxControl. This fact is even documented (see
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Form_Elements_in_the_Document_Model;
it says "Controls are not accessible in the document model. ").

Now, the problem is: the com::sun::star::awt::XListBox interface is
exposed by the frm::OListBoxControl, not the frm::OListBoxModel. So
no way to get at it!

What to do about that? Add a "getCurrentControl(ler)" to the form
element model (com.sun.star.form.FormControlModel)? Duplicate all APIs
in the model (and keep them in the control for backwards
compatibility)?

(see http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Form_Control_Models)

-- 
Lionel