Hi list,
I think I've found a bug or oddity in Win32::GUI::AcceleratorTable and
have vague suggestions on how to improve the already very handy
GridLayout control.
I've discovered that if the accelerator object associated with a window
goes out of scope, the accelerators appear to stop working for that
window. This is quite odd in that I thought Perl's reference counting
would ensure that the object won't get destroyed until all references to
it have been. Surely a window with an accelerator has a reference to
that accelerator, right? Maybe it only stores the handle of the actual
Win32 accelerator table and not a Perl reference, this would explain a
lot.
Here's a barebones script to demonstrate the problem. FIrst the case
where the accelerators are global:
use strict; use warnings; use Win32::GUI;
my $keys = Win32::GUI::AcceleratorTable->new(a => sub{ print "A" });
my $win = Win32::GUI::Window->new
(
-size => [320, 200], -accel => $keys,
-onTerminate => sub { -1 }, -onTimer => sub { print "." },
);
$win->AddTimer(clock => 1000);
$win->Show();
Win32::GUI::Dialog();
This works as expected printing the dots when the timer gets triggered
and printing a when-ever you hit the letter a and the window has the
focus. Now, say we write a sub that returns the main window and
associates it with an accelerator. The differences to the above are the
third statement:
my $win = mainWindow();
and later the almost identical code in the sub:
sub mainWindow
{
my $keys = Win32::GUI::AcceleratorTable->new
(
a => sub{ print "A" }
);
return Win32::GUI::Window->new
(
-size => [320, 200], -accel => $keys,
-onTerminate => sub { -1 }, -onTimer => sub { print "." },
);
} # sub
These changes result in the accelerators not working i.e. the functions
don't get called.
Secondly, I know this is much easier said than done, but would be great
if the GridLayout control could be improved to be more like layout
managers are in other UIs. I see two primary problems with it. As it is
not really a Win32::GUI control in the traditional sense, you cannot
nest grids inside each other for complex layouts. secondly, the grid is
equally spaced as far as I've understood it. Would be nice if it adapted
to the size of the control put in a particular location, so you could
layout a grid without having to worry about the containing controls'
sizes,
Java's Swing has excellent layout managers that fill both gaps I
mentioned but they are fairly complex. I've found that Gnome's take on
things is relatively simple to use and gets most jobs done all right.
Here's a brief and high-level explanation with in-line imagery:
<http://www.gtk.org/tutorial1.2/gtk_tut-4.html>
As GTK+ is open source, I wonder if you could actually borrow some of
the code doing the hard parts and rewrite only Win32 specific bits. The
grid control could then be XS code, too, like most of the Win32::GUI
package appears to be -> at least I cannot find many pm files.
This is minority stuff, but optionally having the grid start its
indexing at $[ would be cool, too. While we're at this, could not you
make a grid object that works like an array or ref to one but let's you
call methods on it? Usage would be more intuitive then. I thought about
this and tentatively concluded that Perl 5 cannot do that. Tied arrays
lose their objectness and having the user directly access object
internals as an array leads one to trouble, even if you'd store object
data at the end or have per-object data as elements in a class array
datum. OBjects that also look like arrays are trivial in, say, Ruby,
though I mostly use Perl because of PPM and all the nifty modules like
Win32::GUI, for example. For me this is an accessibility issue, my
screen reader does not support most 3rd party UIs.
Finally, my machine says:
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches,
and also, Documentation for Win32::GUI v1.03 created 16 Mar 2006
Hope this can be of help.
--
With kind regards Veli-Pekka Tätilä ([EMAIL PROTECTED])
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila
