Ah, the 'implementation' model.
You have found something that is initially confusing (to everyone, let's
face it), but is very nifty.
For Eiffel Vision to be multi-platform, and multi-toolkit, it must deal
with different underlying native toolkits, "implementations" if you
will. There is a gtk implementation and a win32 implementation.
The Eifefel Vision model defines an "interface" class, like EV_GRID,
with has a supplier EV_GRID_I that is an "abstract implementation". In
the abstract implementation class, all of the features needed to get the
job done (from the perspective of the interface class) are identified,
but in most cases not implemented (lots of deferred features).
The concrete "implementation" classes (e.g. EV_GRID_IMP) inherit from,
and provide the actual code for the abstract implementation classes.
You have a version of EV_GRID_IMP for gtk and window, but you have only
one abstract ancestor (EV_GRID_I).
It looks something like this:
EV_GRID ====> EV_GRID_I <---- EV_GRID_IMP
(double line denotes client-to-supplier, and single line denote
child-to-parent relationships
You should not, for normal activites, ever need to deal with either the
*_I or *_IMP classes, except perhaps for amusement.
There are a couple of ways of looking at EV_GRID. Those of us with a
widget orientation like to deal with rows, buut EV_GRID, like most of
its counterparts, is really just a big paint job and so doesn't look,
programmatically, all that much like a complex widget. Still, it's
quite rational.
Create your grid as usual:
create grid
Put it somewhere:
box.extend (grid)
Now configure it. I assume you want no hierarchy, and a few columns:
grid.disable_tree
grid.enable_row_separators
set_column_count_to (5)
-- headers, rows and columns are properties of the grid, and are not
added like widgets in a box
header.i_th (1).set_text ("A clever header label") -- repeat as desired
column (1).set_width (width) -- repeat as desired
Now fill it (this is jut one way)
local
tr: EV_GRID_ROW
ti: EV_GRID_LABEL_ITEM
do
-- Assume some kind of loop on your data source, incrementing i
i := 1
grid.insert_new_row (i)
tr := grid.row (i)
tr.set_data (my_data)
create ti.make_with_txt ("some text")
tr.set_item (1, ti) -- repeat as desired
-- rinse and repeat
You gain access to rows and columns by index, via the grid. I like
rows, but some folks use EV_GRID with items and indices only. Either
works because your simply addressing areas in a paint job. Use what
metaphor you like better.
R
==================================================
Roger F. Osmond
> -------- Original Message --------
> Subject: [eiffel_software] Re: Some questions about
> EV_MULTI_COLUMN_LIST
> From: "ZuLuuuuuu" <
[hidden email]>
> Date: Sat, September 19, 2009 6:41 am
> To:
[hidden email]
> --- In
[hidden email], "ZuLuuuuuu" <canol@...> wrote:
> >
> > --- In
[hidden email], <rfo@> wrote:
> > >
> > > No, and yes.
> > > Multicolumn list does not let you, but EV_GRID does. You can use
> > > EV_GRID to build what appears to be a multicolum list (a grid without
> > > hierachy). There are a variety fo EV_GRID_*_ITEMs, including
> > > EV_GRID_CHECKABLE_LABEL_ITEM.
> > >
> > >
> >
> > Thanks, I'll look at it...
> >
> Hi, I am looking at EV_GRID but I met a concept I didn't see before. There is an EV_GRID_I and an EV_GRID. What are the differences between these? For example, EV_GRID_HEADER wants an EV_GRID_I while creating it and it complains when I just pass an EV_GRID (Non-conforming actual element in feature call). Is there a documentation I can get more info about this subject?
