Hello Frank
Get you now ...
Hm, you kind of misuse the list box to do a calculation, I'd say.
Recognizing this, and handling properly, would require a lot of magic on
OOo side - you don't want each and every list box to reload its content
from the DB with each and every row change. And magic is prone to
breakage, so I try to avoid it.
Instead, I'd say that support for calculated fields is needed in forms.
Something for the feature pool, don't you think?
Could be. But in my oppinion it must be on top. I do not realy
remember how i did the same in another Office DB. But it was near by
the syntax from the Report Builder. You can use:
=[NameOfField] and get the value.
=[count]*[price] get the Sum value.
But you need somtimes values from the subforms or other.
=[NameSubForm].[Formular]![NameOfField] to get the value in the
MainForm. The same for Reports.
And it could be possible to use the same in parameterquerys, i read
in another thread. But there are actually no "spaces" allowed.
:[Formular]![NameSubForm]![NameOfField]
>>> Do you mean something like "Insert/Form" which allows choosing
>>> an existing form, and "embeds" it into the current form?
>> Yes, and it looks like one form.
>
> okay, noted as "allow embedding existing forms into a new form
> (Insert/Form in form design)".
>
> By the way, this is one more thing whose implementation
difficulty > would tremendously decrease if we had dialog-based
forms, instead > of those Writer-monst^Wgiants.
I have a lot of respect for yor work in base, but i have no idea
what difficulty something is or not. So for the forms it could be
good, to make another property in the form:
Something like defaultview: [MainForm] or [TableControl]. So you can
build a form and change only the view to [TableControl] and have
the behaviour from the [TableControl] or back.
I hope you got me.
Ulf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
