Clarion already has browse column management in ABC.
(Don't know how to use it,
see here). So why use
a different one? It comes down to a matter of taste really, but these
are the reasons we created a different one;
- Additional User-Interface features, like Drag & Drop columns
and Right-Click Hide-Column are supported.
- Supports not only Browse Controls, but List controls as well.
- The visual design of the management window shown to the user is
declared inside the ABC Class (called ListFormatManagerClass) inside
a Private method. This means the design will not conform to the
other visual aspects of your application. By contrast RunScreen
requires this procedure to be in your Application tree, so you have
complete control over it.
- The ListFormatManagerClass allows users to create multiple
different layouts for each browse. In our applications each user may
want a different format, but allowing them to create multiple
formats for a single browse is overkill for them. By contrast
RunScreen offers a simpler interface.
- We already have template code (like Secwin) and hand-code in embed points that
manage the which columns are visible or not. So we needed a List
Manager that worked in conjunction with that code and which allowed
other code to control the visibility of certain columns. Also that
code must work on the correct column, even if the column has been
moved by the user.
One really interesting effect of having Runtime Column Management has
been that, as developers, we are more likely to add more fields to a
browse, even if those fields are hidden (ie have a width of zero) by
default. There is less need to exclude columns that have minimal usage,
or which clutter up the screen. We've found in our own apps that we're
able to cater for a wider variety of users, adding the columns that are
only applicable to a few users, while not cluttering up the browse for
the others.
