HList, MListbox, Columns? Database table presentation
Heiko Klein
I'm looking for a widget which nicely and fast displays several columns
(output table from a database). While searching for answers to it, I
stepped over HList, MListbox and Columns. Columns hasn't been developed
further since 1999 (a CPAN installation gave me version 0.01, manual
updating gave a working 0.03 version). It still gave a some warnings.
I applied Shaun Wandler patch (1999, too) to HList to achieve resizeable
columns. The patch hasn't been added to CPAN, and it's still mentioned
(and I can feel it) that there are some things to do.
I didn't try MListbox. It is the latest one (2000) and says everything
this module can do can be done by HList or Columns.
Since those modules are all 3years old. Is there a de facto standard?
HList is implemented in C. Is this a remarkable performance advantage (I
might have up to 10.000 rows)?
I didn't manage to resize a Scrolled HList to more then HList's height.
(Width worked without problems.) Has anybody a hint here? It's defined by:
my $lb = $top->Scrolled("HList",
-font => $font,
-width => 70,
-height => 24,
-scrollbars => 'osow',
-header => 1,
-columns => scalar @columns,
-selectmode => 'extended',
-selectbackground => '#aabbcc'
)->pack(-fill => 'both');
I can see a maximum of 24 rows, no matter how much I resize the window.
(top is the MainWindow, no other widgets).
Heiko
Heiko Klein
added to pack fixed it.
Heiko
Jack D.
news:3E798400...@gmx.net...
> Hi,
>
> I'm looking for a widget which nicely and fast displays several columns
> (output table from a database).
Have you considered TableMatrix ?
<snip>
> Since those modules are all 3years old. Is there a de facto standard?
> HList is implemented in C. Is this a remarkable performance advantage (I
> might have up to 10.000 rows)?
Have you considered TableMatrix ?
>
--
Jack D.
Remove '__' from address if replying by e-mail.
Heiko Klein
TableMatrix seems to be extremely powerful and fast. I went through the
demos, and I have the feeling, that it can do all the tasks I like to
do. The documentation is a bit weak, considering the thousands of
possiblities, but I think, I will try to use this module.
Heiko
Rob Seegel
>demos, and I have the feeling, that it can do all the tasks I like to
>do. The documentation is a bit weak, considering the thousands of
>possiblities, but I think, I will try to use this module.
That is probably the best choice currently. The main advantage of
Tk::Columns and Tk::MListbox is the additional functionality available
that makes some things like sorting built-in. When implementing table
type widgets in the past, I have even found Tk::Columns to outperform
Tk::HList, when doing refreshes (caused by sorts of data). Where Tk::HList
shines is its ability to do things that Tk::Columns or Tk::MListbox are
simply unable to do. These things are mainly of a presentation nature,
such as the ability to apply different styles to each cell. The ability to
embed images, or other widgets. The last is often problematic IMO, but
does work. Often in the past, individuals using Columns or MListbox
have requested the ability to use different colors or fonts for various rows.
Because both of these widgets use Listbox widgets to represent each
column, the best that is possible would be to have each column use
a different font, and/or colors.
If I were looking for one widget myself to serve as a base for a
high-performance,
and offer a highly confligurable set of base properties that I could build
upon,
the TableMatrix would be the stand out choice. Some functionality would have
to be added to provide some of the same capabilities as Columns or MListbox,
but these sorts of additions are not very difficult to do. I've casually
wondered
over the years why no one has yet subclassed this widget to do just that.
I suppose it boils down to requirements. If they are simple, and you need a
quick turn around time, perhaps MListbox or Columns will suffice. If you have
some time and don't mind adding additional functionality yourself, then you
could do it with HList, though it would be better IMO to use TableMatrix. The
documentation could be better, but I think it's mostly sufficient. The major
concern I would have with this widget is that it requires compilation and does
not come with the "default" Tk tarball. So if you're deploying the software to
someone on a different platform, there could be complications depending on the
platform. For the most part this is manageable -- but still something to be
considered.
Rob
Slaven Rezic
> >TableMatrix seems to be extremely powerful and fast. I went through the
> >demos, and I have the feeling, that it can do all the tasks I like to
> >do. The documentation is a bit weak, considering the thousands of
> >possiblities, but I think, I will try to use this module.
>
> That is probably the best choice currently. The main advantage of
> Tk::Columns and Tk::MListbox is the additional functionality available
> that makes some things like sorting built-in. When implementing table
> type widgets in the past, I have even found Tk::Columns to outperform
> Tk::HList, when doing refreshes (caused by sorts of data). Where Tk::HList
> shines is its ability to do things that Tk::Columns or Tk::MListbox are
> simply unable to do. These things are mainly of a presentation nature,
> such as the ability to apply different styles to each cell. The ability to
> embed images, or other widgets. The last is often problematic IMO, but
> does work. Often in the past, individuals using Columns or MListbox
> have requested the ability to use different colors or fonts for various rows.
> Because both of these widgets use Listbox widgets to represent each
> column, the best that is possible would be to have each column use
> a different font, and/or colors.
BTW: Tk804.024 will have itemconfigure/itemcget support for changing
background, foreground, selectbackground and selectforeground colors
in listboxes. (I just submitted a patch to Steve and Nick). Are you
planning to add support for those in Tk::MListbox?
Regards,
Slaven
--
Slaven Rezic - sla...@rezic.de
Lost in your Tk widget tree? Try
http://user.cs.tu-berlin.de/~eserte/src/perl/Tk-WidgetDump/
Frank Herrmann
> I'm looking for a widget which nicely and fast displays several columns
> (output table from a database). While searching for answers to it, I
i have programmed 2 Widgets Tk::DBI::Form and Tk::DBI::Table. Tk::DBI::Table
can display a SQL-Statement in a HList with resizable Columns and Form
display a Dialog Box to edit Data from a tablerow. I have for a couple of
months discover a old TestModul Tk::ResizeButton. I think we add this to
CPAN and we don't have so many question about the right TableModul. I
develop now only my Tables with HList and ResizeButton. This little nice
Widget is very useful for your Problem. Ok, here the facts and Modules (hope
this help):
Example HList:
-----------------
# Special Module
eval('use Tk::ResizeButton;');
my $ERR = 1 if($@);
warn $@ if($@);
# Create HList
unless(defined $obj->{table}) {
my $cols = scalar @fields;
$obj->{table} = $obj->Scrolled('HList',
-scrollbars => 'osoe',
-columns => $cols,
-header => 1,
)->pack(-expand => 1,
-fill => 'both');
$obj->Advertise("table" => $obj->{table}); #TEXT PART.
}
my $hl = $obj->{table};
# create header
my $c = -1;
foreach my $field (@fields) {
$c++;
unless($ERR) {
# create a ResizeButton
$obj->{header}->{$c} = $hl->ResizeButton(
-text => $field,
-relief => 'flat',
-border => -2,
-pady => -10,
-padx => 10,
-widget => \$hl,
-column => $c,
-command => [\&refresh, $obj, $c],
);
# create a header with ResizeButton Widget
$hl->headerCreate($c,
-itemtype => 'window',
-widget => $obj->{header}->{$c},
);
} else {
$hl->headerCreate($c, -text => $field);
}
}
-------------------------
Tk::ResizeButton
-----------------
package Tk::ResizeButton;
#------------------------------------------------
# automagically updated versioning variables -- CVS modifies these!
#------------------------------------------------
our $Revision = '$Revision: 1.3 $';
our $CheckinDate = '$Date: 2003/02/17 16:46:54 $';
our $CheckinUser = '$Author: xpix $';
# we need to clean these up right here
$Revision =~ s/^\$\S+:\s*(.*?)\s*\$$/$1/sx;
$CheckinDate =~ s/^\$\S+:\s*(.*?)\s*\$$/$1/sx;
$CheckinUser =~ s/^\$\S+:\s*(.*?)\s*\$$/$1/sx;
#-------------------------------------------------
#-- package Tk::ResizeButton ---------------------
#-------------------------------------------------
#########################################################################
# Tk::ResizeButton
# Summary: This widget creates a button for use in an HList header which
# provides methods for resizing a column. This was heavily
# leveraged from Columns.pm by Damion Wilson.
# Author: Shaun Wandler
# Date: $Date: 2003/02/17 16:46:54 $
# Revision: $Revision: 1.3 $
#########################################################################=
#####
#
# Updated by Slaven Rezic and Frank Herrmann
#
# XXX needs lot of work:
# * position columnbar correctly and only use MoveColumnBar to move it
instead
# of destroying it and re-creating with CreateColumnBar
# * use Subwidget('scrolled') if it exists
# * don't give error if -command is not specified
# * don't let the user hide columns (minwidth?)
use base qw(Tk::Derived Tk::Button);
Construct Tk::Widget 'ResizeButton';
sub ClassInit {
my ( $class, $mw ) = @_;
$class->SUPER::ClassInit($mw);
$mw->bind( $class, '<ButtonRelease-1>', 'ButtonRelease' );
$mw->bind( $class, '<ButtonPress-1>', 'ButtonPress' );
$mw->bind( $class, '<Motion>', 'ButtonOver' );
return $class;
}
sub Populate {
my ( $this, $args ) = @_;
# CREATE THE RESIZE CONTROLS
my $l_Widget;
for ( my $i = 0 ; $i < 2 ; ++$i ) {
$l_Widget = $this->Component(
'Frame' => 'Trim_' . $i,
-background => 'white',
-relief => 'raised',
-borderwidth => 2,
-width => 2,
);
$l_Widget->place(
'-x' => -( $i * 3 + 2 ),
'-relheight' => 1.0,
'-anchor' => 'ne',
'-height' => -4,
'-relx' => 1.0,
'-y' => 2,
);
}
$l_Widget->bind( '<ButtonRelease-1>' => sub { $this->ButtonRelease(1); } );
$l_Widget->bind( '<ButtonPress-1>' => sub { $this->ButtonPress(1); } );
$l_Widget->bind( '<Motion>' => sub { $this->ButtonOver(1); } );
$this->SUPER::Populate($args);
$this->ConfigSpecs(
-widget => [ [ 'SELF', 'PASSIVE' ], 'Widget', 'Widget', undef ],
-column => [ [ 'SELF', 'PASSIVE' ], 'Column', 'Column', 0 ],
-minwidth => [ [ 'SELF', 'PASSIVE' ], 'minWidth', 'minWidth', 50 ],
);
# Keep track of last trim widget
$this->{'m_LastTrim'} = $l_Widget;
}
sub ButtonPress {
my ( $this, $p_Trim ) = ( shift, @_ );
$this->{'m_relief'} = $this->cget( -relief );
if ( $this->ButtonEdgeSelected() || $p_Trim ) {
$this->{'m_EdgeSelected'} = 1;
$this->{m_X} = $this->pointerx() - $this->rootx();
CreateColumnBar($this);
} else {
$this->configure( -relief => 'sunken' );
$this->{m_X} = -1;
}
}
sub ButtonRelease {
my ( $this, $p_Trim ) = ( shift, @_ );
$this->{'m_EdgeSelected'} = 0;
$this->configure( -relief => $this->{'m_relief'} );
if ( $this->{columnBar} ) {
$this->{columnBar}->destroy;
undef $this->{columnBar};
}
if ( $this->{m_X} >= 0 ) {
my $l_NewWidth = ( $this->pointerx() - $this->rootx() );
my $hlist = $this->cget( -widget );
my $col = $this->cget( -column );
$$hlist->columnWidth( $col, $l_NewWidth + 5 )
if(($l_NewWidth + 5) > $this->cget( -minwidth ));
$this->GeometryRequest( $l_NewWidth, $this->reqheight(), );
} elsif ( !$this->ButtonEdgeSelected() ) {
$this->Callback( -command );
}
$this->{m_X} = -1;
}
# CHECK IF THE RESIZE CONTROL IS SELECTED
sub ButtonEdgeSelected {
my ($this) = @_;
{
return ( $this->pointerx() - $this->{m_LastTrim}->rootx() ) > -1;
}
}
# CHANGE THE CURSOR OVER THE RESIZE CONTROL
sub ButtonOver {
my ( $this, $p_Trim ) = @_;
my ($cursor);
my $hlist = $this->cget( -widget );
if ( $this->{'m_EdgeSelected'} || $this->ButtonEdgeSelected() || $p_Trim )
{
if ( $this->{columnBar} ) {
$this->{columnBar}->destroy;
CreateColumnBar($this);
}
$cursor = 'sb_h_double_arrow';
} else {
$cursor = 'left_ptr';
}
$this->configure( -cursor => $cursor );
}
# Create a column bar which displays on top of the HList widget
# to indicate the eventual size of the column.
sub CreateColumnBar {
my ($this) = @_;
my $hlist = $this->cget( -widget );
my $height = $$hlist->height() - $this->height();
my $x = $$hlist->pointerx() - $$hlist->rootx();
# my $x = $this->rootx + $this->width - $$hlist->rootx;
$this->{columnBar} = $$hlist->Frame(
-background => 'white',
-relief => 'raised',
-borderwidth => 2,
-width => 2,
);
#FIXFIX: Some fudge factors were used here to place the column
# bar at the correct place. It appears that hlist->rootx is
# relative to the scrollbar, while when placing the columnbar
# the x location is relative to hlist widget. This definitely
# doesn't work when using a non-scrolled hlist.
$this->{columnBar}->place(
'-x' => $x,
'-height' => $height - 5,
'-relx' => 0.0,
'-rely' => 0.0,
'-y' => $this->height() + 5,
);
}
1;
---------------------------
--
xpix - - - http://xpix.dieserver.de
Rob Seegel
>background, foreground, selectbackground and selectforeground colors
>in listboxes. (I just submitted a patch to Steve and Nick). Are you
>planning to add support for those in Tk::MListbox?
Yes. I tried using TextList, but there was a large performance hit, so
I've been waiting for the new and improved Listbox, that should make
this happen. I also have a few fixes for MListbox that will be going out
soon. Something else that folks may want is the ability to use
different fonts (one per row). Will that also be possible with the patch?
Rob
Slaven Rezic
No.
Regards,
Slaven
--
Slaven Rezic - sla...@rezic.de
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
Heiko Klein
possibilities of Column or MListbox, I prefer the build-in sorting
capabilities of my database (it's more sensitive to data (correct
date,numerical,alphabetical-sorting ...)).
I tested the following:
Tcl/Tk Listbox implementation
Perl/Tk HListbox implementation
Perl/Tk MListbox implementation
Perl/Tk TableMatrix implementation
The task was fetching and presenting 25.000 rows, 10 columns from a
database.
The Postgres Database needs about 15s to fetch the data. (Athlon 850MHz)
The Tcl/Tk Listbox presents the data after something like 30s, using 30MB.
The TableMatrix presents the data after 40s, needing 70MB.
The Hlist takes 75s and needs a bit more than 100MB.
The MListbox takes 90s and needs 50MB.
All tables/Lists have been filled at once.
On the contrary, OpenOffice - Datasource Viewer seems to present the
data instantaneously (after the interaction with the database), with
only spending 15MB of extra memory (so 60 in Total). It is cheating,
sure. I never get the whole table, but an excerp of some lines. Access
is handling database-presentations similar.
I will use TableMatrix, mainly because I need resizing of columns and
the possibility to get cell-content into the mouse-buffer.
Is there a way to align the contents? Right now eveything is centered,
and I would like to have it aligned to the left.
Heiko
kz15
Jack D. wrote:
<chainsaw>
> Have you considered TableMatrix ?
I also looked at this module (against Tk::Columns, which I am currently
using) and IMO I would also gain some performance switching over to
TableMatrix.
I might have skipped something while RTFM-ing, but I haven't seen in the
POD anything on how to make a cell 'read-only', so that the user could
not change the contents of a cell. Can someone provide me a hint on this?
Thanks a lot in advance,
Zoltan
<chainsaw>
Heiko Klein
cell (and thus, change the contents).
------------------------------------------------------------------------------
use Tk::TableMatrix;
{
# disable activating of a cell, making the table readonly
local $^W = undef;
*Tk::TableMatrix::activate = sub {};
}
-------------------------------------------------------------------------------
Heiko
Heiko Klein
running the code). I tried now putting everything into an array and
loading all rows by $ml->insert('end', @all).
This gives: 40s and needs 90MB. (90MB instead of 50MB because it seems
to keep a reference to @all, thus keeping the data in the widget, and in
the reference (so, when I try to keep an additional array, it contains
only 25MB???)).
And I load the HList element by element, since I don't know how to load
everything with one command.
Heiko
Slaven Rezic
There's no method for "mass-filling" HList widgets.
Another idea for reducing the memory footprint: implement some kind of
"lazy" listbox. This would only hold the visible portion of the data
in the widget and add data to the widget only if needed, i.e. when
scrolling in the widget. A sample implementation can be downloaded
from:
http://user.cs.tu-berlin.de/~eserte/src/perl/Tie-Listbox/
Regards,
Slaven
--
Slaven Rezic - sla...@rezic.de
tktimex - project time manager
http://sourceforge.net/projects/ptktools/
Ron Smith
>
> Heiko Klein <Heiko...@gmx.net> writes:
>
> > I have to correct myself on behalf of MListbox (forgot to save before
> > running the code). I tried now putting everything into an array and
> > loading all rows by $ml->insert('end', @all).
> > This gives: 40s and needs 90MB. (90MB instead of 50MB because it seems
> > to keep a reference to @all, thus keeping the data in the widget, and in
> > the reference (so, when I try to keep an additional array, it contains
> > only 25MB???)).
> >
> > And I load the HList element by element, since I don't know how to load
> > everything with one command.
> >
>
> There's no method for "mass-filling" HList widgets.
>
Sure there is!
perl << 'END'
use Tk;
$mw=MainWindow->new;
my $h=($mw->Scrolled('HList')->pack->children)[0];
print "$h\n";
@array=qw(one two three four five);
map {$h->add($_,-text=>$_)} @array;
MainLoop;
'END'
Its called "map".
:-)
OK, ok, ok. You don't like that because it doesn't have '->'
perl << 'END'
use Tk;
$mw=MainWindow->new;
my $h=($mw->Scrolled('HList')->pack->children)[0];
print "$h\n";
@array=qw(one two three four five);
sub Tk::HList::massFill {
my $self=shift;
map {$self->add($_,-text=>$_)} @_;
}
$h->massFill(@array);
MainLoop;
'END'
;-)
Rob Seegel
> Thanks for all the answers. In my case, I don't need the sorting
> possibilities of Column or MListbox, I prefer the build-in sorting
> capabilities of my database (it's more sensitive to data (correct
> date,numerical,alphabetical-sorting ...)).
Which is good, dealing with the amounts of data you're talking
about will likely be more efficient to let the database sort it. Of course,
creating a subclass that couples the widget to DBI could limit it's reusability
(if that's a concern).
>
> I tested the following:
>
> Tcl/Tk Listbox implementation
> Perl/Tk HListbox implementation
> Perl/Tk MListbox implementation
> Perl/Tk TableMatrix implementation
>
> The task was fetching and presenting 25.000 rows, 10 columns from a
> database.
It would be interesting to see your test cases, so I could
see if I might be able to optimize them somewhat. When you are dealing with
large amounts of data, you are going to want to minimize the number of perl
calls required to add it to the widget. It's best to get to the underlying C
code as fast as possible. The more methods you use to get the data to the C
core of the widget, the slower it's going to be.
Within a Listbox, for example you can pass an array to one method call, and
then the core c implementation takes it from there. Which in terms of speed
will be the quickest, but will also mean that you will have to have an array
that holds all those elements in memory, so it will use more memory. Compare
this to inserting each element row by row -- that is 25K method calls to insert
the same data. Suffice to say it will be much slower.
Now, contrast this to a composite widget like Columns or MListbox.
In both of these widgets each column is a separate Listbox. If each
row is inserted one at a time, the total number of calls can go up to
at least 250K! Tk::Columns does have a rather nice and underdocumented feature
that allows you to load an array of array references. in one insert. The result
is a blazingly quick insert (I was able to insert that size in under 5 seconds
in a test case). This is an optimization that will be in the next version of
MListbox.
Essentially, the optimization is that Tk::Columns separates the data
into an array for each column. In this way it does 10 inserts instead
of 250K or even 25K. Of course, this approach is even more expensive memory
wise for very large datasets.
It should be possible to strike some middle ground -- break your
result sets in groups of 5K or less, and do inserts on each group. This may
save you some memory, but he lower the number, the longer the inserts will
take.
But consider this from another viewpoint. Is it really the actual
slowness of the table population that bothers you? What if the
widget didn't wait until it was done loading the data to start
showing it. In the past, I've implemented a widget somewhat similar
to what Frank Herman mentioned using HList. I needed some of the
extra functionality that HList provided. The problem is that you pay
for that functionality in speed. I implemented that widget to have
a configurable value called updateinterval and also a progressvar
(that worked like textvariable) that contained the percentage of
data loaded. If the updateinterval was set, then after every x
number of rows were inserted, I'd update the percentage complete,
and then call the update() method. I had a progressbar at the bottom
of the gui that was able to be tied into progressvar.
Now, interrupting the inserts is obviously going to result in
slower load times, but this might not be too critical. The end
user is going to see data almost immediately because of the updates -- just not
all at once. The trade off worked well in that case, because none of my end
users were physically capable of reading 5K rows in the blink of an eye -- let
alone 25K. They were able to use the widget as data continued to be loaded, and
the progress bar was a help so that they had some idea when it was finished. It
sure beats having the application freeze up while waiting!
Rob
Heiko Klein
excellent. Its really difficult to say which List-implementation is the
nicest. (Now I tend again towards MListbox plus progressbar...)
I attach the test-cases. They won't run without my database, but they
should give an overview how I implemented the lists. They are mostly
derivates of one of the demos. (I consider the tcl/tk implementation a
mess, that's why I'm rewriting it. The filling of the listbox is somehow
scattered over 5000 lines of code...)
Heiko
Bharat Pondugula
I am looking for guidance regarding the "Good morning all,
I am looking for guidance regarding Database applications in perl
tk/gtk. I am planning to build an application (pretty database
intensive about a million records , reads, writes) with GUI frontend
in either PERL GTK or PERL TK. Do you think that the application will
be fast enough.
Thanks in advance
Bharat Pondugula
Heiko Klein <Heiko...@gmx.net> wrote in message news:<3E7EF36C...@gmx.net>...
Heiko Klein
the most important question is: Is your database fast enough?
Read/writes are connected to the database implementation, not the
language or GUI used. The second question: Do you have enough memory? I
just learned that I can speed up the table presentation by showing a
sets of 500 columns instead of 25000 at once (Presentation of 500columns
takes about 0.5s, while the pure database-selection of the 25000 row
takes 10s.)
You will like to have some kind of SQL-Perl mapping (as you would like
to have in any other language, too). I'm currently using Class::DBI,
which works really nice, though it is still in a heavy development state
(but not unstable: You simply have to freeze one version to your database.)
I was thinking about GTK, TK or QT as GUI. Perl/QT has just been
completely rewritten after it has been dead for a year or two. Now it's
Perl/QT3. GTK can be connected to glade, a GUI-Builder, which might be
nice. But Perl/GTK hasn't been updated in 1 1/2 years. And I've just
seen, there is Perl/GTK2 which has a new maintainer and seem to be a
rewrite, too. Perl/Tk is still connected to version 8 of Tk, which is a
bit old by now (i.e. Unicode, Wheelmouse missing ...) I think I heard
rumours of a 8.2 or 8.4 version, but don't know about the state. And Tk
in itself is known to look a bit old-fashioned.
So this is all not completely satisfying, here are my reason why I
choose Tk as toolkit:
Good and handy documentation + book (Mastering Perl/Tk)
Very much used: (maybe to much, there are 662 modules on CPAN about Tk)
Known to be stable
DeFacto Standard for scripting languages (TCL,Perl,Python)
Cross-platform (I use it on Win and X11)
And I have used it two years ago, so I knew it a bit (okay, this is a
very personal reason, but it was very useful for me!).
Speed of execution is okay. If you want to be faster, what can you use?
Java/C/C++: I guess it takes at least 5 to 10 times as long to program
in those languages than it takes in perl.
Access/VBA: Ugly language, bound to Microsoft, expensive, but excellent
and fast widgets. I guess you will be able to create quite a fast GUI
when you use the Access widgets. (You still may connect it to any ODBC
database.)
TCL/Python: TCL should be the fastest, since the integration of Tk is
best. I don't like the language. Python will be slower since it uses a
tcl wrapper to connect to TK. ObjectOrientation is excellent in Python.
Concerning database-connection and speed of language: Perl seems to be
among the fastest scripting languages.
Heiko
smackdab
"Rob Seegel" <robs...@aol.com> wrote in message
news:20030323092003...@mb-cc.aol.com...
Hi Rob, would you consider adding a "extend last column" to MListbox
in an upcoming release? (TableMatrix has this and I thought it was very
useful)
Rob Seegel
>in an upcoming release? (TableMatrix has this and I thought it was very
>useful)
I'll take a look at it. It doesn't sound too tough, but columns can be moved
around in MListbox. I
Rob
smackdab
Good point...I guess I am stuck deciding should my "table" type views always
fit in the
size of the window the user created (ie extend last column) or should the
widget be
scrollable?
For example, I have a list of messages at the bottom of my app, which I
currently use MListbox for.
The user can save/restore the size of the columns, so sometimes during
resizing you need
to scroll to see everything...do you have any "best practice" GUI thoughts
on this ;-)