Forms definition features request

[Robert Jenkins]

Hi,

I was hoping to use GNUe forms as a front end for a database project
that I'm currently working on, but unfortunately in it's present state,
it's just not got the capabilities I need. Hopefully I will be able to
use a future version.


There are a few additions to the form definitions that I think will be
needed for many potential applications, not just my own.


1: Facility for accurate positioning of elements on a graphical form.
i.e. In the form definition, add something like 'x-scale' and 'y-scale'
to define the minimum screen resolution required for the form. 
All coordinates & sizes of elements would then be scaled from these
values.
If these default to 80 x 24 when not explicitly given, then present form
definitions should work with existing character coordinates.

(Would'nt is be advisable to change over to higher resolution 'graphics
friendly' coordinates as soon as possible? Surely it's going to be
easier than converting more complex code in the future?)


2: Block definitions; add capability for subforms / tables (so the whole
block can be repeated as either multiple forms or a table).
Change from 'rows' to minrows & maxrows to set limits for variable-size
subforms??

Add 'scroll' boolean to give scrollbar if there is more data to display
than '(max)rows'.

Add 'suppress-labels' (after first row) option. A subform could be
defined as repeated, complete form, where both labels and entries are
duplicated, or as a single row of elements with labels above it, which
gives a 'columns with headings' effect when displayed with labels
suppressed (and rowspace set correctly).

Add x / y / height / width so a block can be accurately positioned
within the form or page.

Add 'frame' or 'border' boolean to allow display of a box around the
block.

Add 'label' value to display text inset in the frame. Alternatively to
these two, use 'box' to give visual, as opposed to logical, grouping.

Add 'line' or 'divider' to display a horizontal seperator.

Make all coordinates relative to the 'parent' form / page / block etc.
Elements in a block really need the position & size to be referenced to
the parent object, rather than the form size. Absolute values can easily
be calculated at run time, but for a complex or multipage form, it's a
lot easier to read the definitions relative to the current block or page
rather than the start of the form. (Possibly only when form x-scale is
>120 or 'requiregui' is set etc., so it works just for
graphics-mode-only forms). It would also make life a LOT simpler in
cases where multi page forms are displayed by page swapping rather than
scrolling.

Add foreground & background colour parameters to all displayable
elements. (I know it's rather low priority...)


3: 'Entry' changes / additions:
Change max-length to allow (e.g) 5.2 format for numeric values.

Case / typecase / style - these overlap and seem redundant. If 'style'
had options such as
Label, text, upper, lower, alpha, date, time, choice (or dropdown),
boolean, y/n, checkbox etc.
then case and typecase are not needed.

Add 'minval' & 'maxval' for setting limits on numeric values

Add means to explicitly define a virtual field (i.e. for calculated
values or data derived from a relationship that is not to be stored).
Possibly just reserve 'virtual' as the 'field' name?

Add 'derivation' option to give source "formula" for data to be
displayed in virtual fields?

Possibly add a 'group' parameter to elements? So all elements with a
specific 'group number' are are updated when any other element in that
group is changed, for example to update a virtual 'tax' field on a price
entry.

 - What I'm thinking of is something understandable to Joe User.
Numbered groups and basic spreadsheet style derivation formulas are a
crude way of automating updates, but the majority of users will
understand the concepts and be able to create simple apps, where few
will understand trigger scripts written in python, regardless of how
essential these are for serious application. 



4: 'label' does not have a 'height' parameter, this would be needed for
scaleable graphic display.
 - I notice 'label' is mentioned as an option for 'style' in the 'entry'
section of the docs - is 'label' going to be redundant as a separate
entity?


5: Both entry and label need view / edit security control. For many
business apps, different users need different access to certain elements
of a standard form.

If 'hidden' and 'readonly' could have a numeric setting (as well as just
true/false), this would make element-specific security simple - only
display the element (or label) if it's 'hidden' parameter is >= the
security level and likewise for 'readonly' to control editing. 1 =
enabled at lowest level, higher values = higher security (up to, say, 9
for highest level.)

The labels need the same facility as it's a bit obvious to users that
data is being hidden if it's label is still visible!

If the default security level is '1' and true equates to 0 / false
equates to 1, existing code would still work.



P.s. Please keep the docs on the web site more up to date - for example
the 'forms' tech refs are many versions older that the ones in the
source packages and anyone downloading those old docs to get an overview
of GNUe will get a very in-accuarate impression.


Regards,

Robert Jenkins,
JRW Developments.
mailto:address@hidden