[RE: [[lazarus] GTK Z order & fixed frame]]

[Samuel Liddicott]

> -----Original Message-----
> From: Michal Bukovjan [mailto:mbukovjan at netscape.net]
> Sent: 30 August 1999 06:49 PM
> To: lazarus at miraclec.com
> Subject: Re: [RE: [[lazarus] GTK Z order & fixed frame]]

> rectangle. Unlike Win32 listbox, which has one big canvas for all of its
> lines, the GtkListBox approach (which I find cool :-) is that for
> each line
> (item) it contains another container, GtkItem, and this another container
> (descendant of GtkContainer, GtkBin - designed to hold just one
> child), may or
> may not hold a GtkLabel (which provides Canvas). The label holds
> and paints
> the text.
> This OwnerDrawing would require to create an arbitrary control on
> the fly, and
> put it instead of the GtkLabel, which is not a problem. The
> problem is in the
> structure of the OwnerDraw event, which would point to different
> rectangles,
> but that need not be a problem, too.

Yes. The OwnerDraw handler for a list box is called once for each visible
item, and passes a rect but not a canvas.  Shame.
Perhaps we could switch in a different canvas just while that function is
called.  Hmmm.

> Your approach, to create one big control with one canvas might also be a
> solution, but then a complete selection and focus management
> would have to be
> reprogrammed for TListBox :-(

Yeah.  How about a meta-canvas which takes a set of canvases and regions and
breaks down the drawing into sets of operations on the various impinged
canvases.

Hey... this is what metafile printing does....

Anyway, just daydreaming here...

> > It seems that the only things which may affect how things work
> then, are:
> >
> > Z order stetting
Can a control be hidden and shown without removing from the gtk parent-child
structures?

Sam