Re: Updates about Enhanced Database Ranges.

Hey devs,

Thank you moggi and kohei for helping me out on the IRC constantly.

With the design I am describing now, the feature becomes an n-ternating
(not alternating) row formatting (not just colouring) feature. Please help
with your advice and discussions.

The feature design can be compartmentalised as follows:
1. The 'Row Formatting definition' part, where used selects the targeted
database range and the styles to be applied to it.
2. The 'Row Formatting core' where DB Range code and this feature interact.
3. The rendering end.

*Row Formatting definition:
*

*[Data Structures]*

About the storage of this formatting information and how alternating
formatting info will be defined:

   - User defines each alternating format as a band, and as such 'n' number
   of bands constitute particular n-ternating format. The user select the
   formatting options and the size of the band i.e, how many consecutive rows
   it will cover/applied to. When the user defines another band, the new band
   will follow the previously defined band. Thus we can have more than just
   alternating colours for our DB ranges. Eg. define first band of size 1 and
   bold text, band 2 of size 3 italic text and band 3 of size 1 underlined
   text; for a range of 10 rows, the first will be bold followed by 3 italic
   rows followed by 1 underlined row and so on..


   - Every defined band for an Alternating row format will be stored as a
   ScDBDataRowFormat that will have the attributes: 1. index number which
   helps define the sequence of these bands 2. band size 3. Formatting
   information (ScStyleSheet instance??). It has its method GetStyle() that
   returns the style to be applied


   - Many such ScDBDataRowFormat instances are added to a container which
   is a part of ScDBDataRowFormatting object. This object represents the total
   style you have created and also contains the defined style name you give to
   it.


   - All such defined styles are added to a pool of ScDBDataRowFormatting
   objects; lets say this pool is represented by
   ScDBDataRowFormattingCollection (the names are getting scarily long), so
   styles once custom defined can be used again and again.

Associating every ScDBData object with it's ScDBDataRowFormatting object:

   - Every ScDBData object has an attribute of type ScDBDataRowFormatting
   which is assigned to it by picking it up from the
   ScDBDataRowFormattingCollection pool.
   - Thus many DB Ranges can use the same style without having to have any
   multiple copies to themselves.

*Row Formatting Core:*

The row formatting core is composed of the modifications needed in ScDBData
itself to support the new alternating colour functionality.

ScDBData will have a new method GetRowFormatting() just like the one in
conditio.cxx (GetData()); however this will return a ScDBDataRowFormatting
object.

The rendering half will have to iterate over each row of the the range
while iterating over the ScDBRowFormat items in the container in
ScDBRowFormatting instance taking care of the band size of each and thus
applying it to the row cells accordingly. This makes the rendering code a
little more complicated as multiple styles have to be related to different
rows.

Events (not actually events) in ScDBData such as:

   - UpdateMoveTab - changes the table
   - UpdateReference()
   - ExtendDataArea - extends/shrinks the area under ScDBData

make changes to the structure and coverage of the defined database range.
We need to take care of such events that may wipe out or add newer rows to
the range. Such updates set the bModified bool in ScDBData, this needs to
be known and be handled by the rendering half of this feature.

*The rendering end:*

This rendering end is the something I am discovering with each passing day.
Not much to write here.

*Some design issues:*

I see one big problem with the way this are laid out now. The formatting
information and ScDBData's bounds (i.e its rows) are very decoupled. It
becomes the job of the rendering end to apply the correct formatting by
iterating over the ScDBRowFormatting container and getting the
ScDBRowFormat objects taking care of their band sizes as it moves over each
row adding in the formatting information.

This makes the rendering end very complicated (maybe). Since rendering is
not just taking the concerned rows and style and shoving in the attributes.
One way out can be having a member function in ScDBData that returns an
array of  size[No.OfRows], each entry containing the applicable stylesheet
for that row. This shifts the 'making sense of' part, out of the rendering
part.
*[UI Stuff]
*
Speaking of what to call this functionality and where to place it in the
menu hierarchy:
Either we can:

   - Greet the user with the same dialog as seen in Calc's Data->Select
   Range, from where the user selects a range to be formatted as table i.e,
   coloured alternately.
   - Or, since clicking format as table option in MS Excel marks a bunch of
   cells as a table with a name, which 'optionally' can be coloured; we will
   need to incorporate the alternate colouring option in the Data -> Define
   Range dialog in its 'more' section.

In any case once this option is clicked, the user must define a custom
design or choose from a few existing ones, just like in Excel.

Thank you for listening.