Tk::ErrorDialog not working for me - bug?

Hi all,

I've been happily hacking away at an application that makes use of
Tk::ErrorDialog for handling exceptional circumstances. I'm running it
on W2K & XP boxes with ActiveState 5.6 & 5.8: the 5.6 boxes run fine
but the 5.8 boxes all fail to show any Tk::ErrorDialog even when
running the minimal script below...

#!perl -w
use strict;
use Tk;
use Tk::ErrorDialog;
my $mw = new MainWindow();
sub go {
die "screaming";
}
$mw->Button(-text => 'Go', -command => \&go)->pack;
MainLoop;

...the system bell sounds but surprisingly no error dialog appears.
When the app terminates however I get some complaints on STDERR or
STDOUT...

Background Error: window ".errordialog.dialog" was deleted before its
visibility
changed at C:/progs/perl/site/lib/Tk/Widget.pm line 926.

...seemingly one per button press and only very occasionally lots of
this...

Background Error: window ".errordialog.dialog" was deleted before its
visibility
changed at C:/progs/perl/site/lib/Tk/Widget.pm line 926.
Background Error: XStoSubCmd: Not a Tk Window
Tk::die_with_trace at C:/progs/perl/site/lib/Tk/ErrorDialog.pm line
96
Tk::Error at C:/progs/perl/site/lib/Tk/Widget.pm line 926
(eval) at C:/progs/perl/site/lib/Tk/Widget.pm line 926
Tk::Widget::waitVisibility at blib\lib\Tk\Wm.pm (autosplit into
blib\lib\auto\T
k\Wm\Popup.al) line 135
Tk::Wm::Popup at C:/progs/perl/site/lib/Tk/DialogBox.pm line 106
Tk::DialogBox::Show at C:/progs/perl/site/lib/Tk/ErrorDialog.pm line
105
Tk::Error at C:/progs/perl/site/lib/Tk.pm line 406
(eval) at C:/progs/perl/site/lib/Tk.pm line 406
Tk::MainLoop at tkerrortest.pl line 10

...like I say, it's only on the 5.8 perls, all my 5.6 boxes operate as
documented. If anyone has any clues I would be greatly appreciative as
its stalling rollout of a rather fine (IMHO) application. I'm not sure
how to ask Tk for its definitive version so here's a section of Tk.pm
that looks relevant...

# Record author's perforce depot record
$Tk::CHANGE      = q$Change: 3279 $;

# $tk_version and $tk_patchLevel are reset by pTk when a mainwindow
# is created, $VERSION is checked by bootstrap
$Tk::version     = '8.4';
$Tk::patchLevel  = '8.4';
$Tk::VERSION     = '804.027';
$Tk::XS_VERSION  = $Tk::VERSION;
$Tk::strictMotif = 0;

...and here's a typical perl -V of a "broken" 5.8 platform (NB: fresh
ActivePerl-5.8.4.810-MSWin32-x86.msi installs)...

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=def
ine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -
DNO_STRICT -DHAVE_DES_FCRYPT  -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPL
ICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-MD -Zi -DNDEBUG -O1',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='__int64', lssi
ze=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf
-libpath:"C:
\progs\perl\lib\CORE"  -machine:x86'
libpth=C:\PROGRA~1\MICROS~3\VC98\lib
libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32
.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib
uuid.lib wsoc
k32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib
msvcrt.lib
perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib
winspool.lib  comd
lg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib
uuid.lib
wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-opt:ref,icf  -
libpath:"C:\progs\perl\lib\CORE"  -machine:x86'


Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_
CONTEXT PERL_IMPLICIT_SYS
Locally applied patches:
ActivePerl Build 810
22751 Update to Test.pm 1.25
21540 Fix backward-compatibility issues in if.pm
Built under MSWin32
Compiled at Jun  1 2004 11:52:21
@INC:
C:/progs/perl/lib
C:/progs/perl/site/lib

On 3 Sep 2004 02:13:48 -0700, msemtd@yahoo.co.uk (UnFormat) wrote:

>I've been happily hacking away at an application that makes use of
>Tk::ErrorDialog for handling exceptional circumstances. I'm running it
>on W2K & XP boxes with ActiveState 5.6 & 5.8: the 5.6 boxes run fine
>but the 5.8 boxes all fail to show any Tk::ErrorDialog even when
>running the minimal script below...
>
>#!perl -w
>use strict;
>use Tk;
>use Tk::ErrorDialog;
>my $mw = new MainWindow();
>sub go {
>    die "screaming";
>}
>$mw->Button(-text => 'Go', -command => \&go)->pack;
>MainLoop;
>
>...the system bell sounds but surprisingly no error dialog appears.
>When the app terminates however I get some complaints on STDERR or

Well just for your troubleshooting, the script works fine on linux.
So it's windows related.


--
I'm not really a human, but I play one on earth.
http://zentara.net/japh.html

UnFormat wrote:

> Hi all,
>
> I've been happily hacking away at an application that makes use of
> Tk::ErrorDialog for handling exceptional circumstances. I'm running it
> on W2K & XP boxes with ActiveState 5.6 & 5.8: the 5.6 boxes run fine
> but the 5.8 boxes all fail to show any Tk::ErrorDialog even when
> running the minimal script below...

I've found that Tk can be a little fussy about trying to quit without
cleaning up first. It often doesn't die() gracefully. You may be
better off using a warn and exit(). That will give it a chance to
clean up after itself.

>
> #!perl -w
> use strict;
> use Tk;
> use Tk::ErrorDialog;
> my $mw = new MainWindow();
> sub go {
>     die "screaming";
warn "screaming" and exit();
> }
> $mw->Button(-text => 'Go', -command => \&go)->pack;
> MainLoop;

thundergnat <thundergnat@hotmail.com> wrote...

> I've found that Tk can be a little fussy about trying to quit without
> cleaning up first. It often doesn't die() gracefully. You may be
> better off using a warn and exit(). That will give it a chance to
> clean up after itself.

I think you misunderstand the issue here: Tk::ErrorDialog purposefully
overrides the core die() to provide a dialog box with an error
message. It appears to be broken on certain platforms (see original
post).

Regards,
Michael.

zentara wrote:
> Well just for your troubleshooting, the script works fine on linux.
> So it's windows related.

Yup - it's just NT4/W2K/XP with ActiveState 5.8.

So, any ideas... anyone? please?   :)

UnFormat wrote:

> Hi all,
>
> I've been happily hacking away at an application that makes use of
> Tk::ErrorDialog for handling exceptional circumstances. I'm running it
> on W2K & XP boxes with ActiveState 5.6 & 5.8: the 5.6 boxes run fine
> but the 5.8 boxes all fail to show any Tk::ErrorDialog even when
> running the minimal script below...
>
> #!perl -w
> use strict;
> use Tk;
> use Tk::ErrorDialog;
> my $mw = new MainWindow();
> sub go {
>     die "screaming";
> }
> $mw->Button(-text => 'Go', -command => \&go)->pack;
> MainLoop;
>
> ...the system bell sounds but surprisingly no error dialog appears.
> When the app terminates however I get some complaints on STDERR or
> STDOUT...
>
> Background Error: window ".errordialog.dialog" was deleted before its
> visibility
>  changed at C:/progs/perl/site/lib/Tk/Widget.pm line 926.

Yep, that's a documented but well hidden behaviour.

Tk::Errolevel calls the withdraw method on the created toplevel window.

perldoc Tk::Wm

tells us:

$toplevel->withdraw
Arranges for $toplevel to be withdrawn from the screen. This causes the
window to be unmapped and forgotten about by the window manager. If the
window has never been mapped, then this method causes the window to be
mapped in the withdrawn state. Not all window managers appear to know how
to handle windows that are mapped in the withdrawn state. Note: it
sometimes seems to be necessary to withdraw a window and then re-map it
(e.g. with deiconify) to get some window managers to pay attention to
changes in window attributes such as group.

This seems to be the case for the Win32 window manager, but Tk::Errorlevel
doesn't do a deiconify before trying to show the dialog.

Here a patch that fixes this

--- ErrorDialog.pm      Sun Dec 14 19:44:50 2003
+++ patches\ErrorDialog.pm      Wed Sep 08 15:24:32 2004
@@ -101,6 +101,7 @@ sub Tk::Error {
my($d, $t) = ($ED_OBJECT->Subwidget('error_dialog'),
$ED_OBJECT->Subwidget('text'));
#   chop $error;
$d->configure(-text => "Error:  $error");
+    $d->deiconify;
$d->bell;
my $ans = $d->Show;

Perhaps this should be included in future releases?

Thomas

--
open STDIN,"<&DATA";$=+=14;$%=50;while($_=(s( #J~.> a>n~>>e~.......>r.
STDIN,$:*$=+$,+$%,0),getc)){/\./&&last;/\w| /&&( #.u.t.^..oP..r.>h>a~.e..
print,$_=$~);/~/&&++$:;/\^/&&--$:;/>/&&++$,;/</  #.>s^~h<t< ..~. ...c.^..
&&--$,;$:%=4;$,%=23;$~=$_;++$i==1?++$,:_;}__END__#....>>e>r^..>l^...>k^..

Thomas Kratz wrote:
> Here a patch that fixes this

Thanks Thomas but the patch doesn't change anything on my broken platforms.
Any more ideas out there or a confirmation that it's a bug?

Regards,
msemtd.

msemtd@yahoo.co.uk wrote:

> Thomas Kratz wrote:
> 
>
>
> Thanks Thomas but the patch doesn't change anything on my broken platforms
.
> Any more ideas out there or a confirmation that it's a bug?

Sorry, diffed the wrong file:

make that:

+    $ED_OBJECT->deiconify;

That does it for me with your original example.

Thomas

--
open STDIN,"<&DATA";$=+=14;$%=50;while($_=(s( #J~.> a>n~>>e~.......>r.
STDIN,$:*$=+$,+$%,0),getc)){/\./&&last;/\w| /&&( #.u.t.^..oP..r.>h>a~.e..
print,$_=$~);/~/&&++$:;/\^/&&--$:;/>/&&++$,;/</  #.>s^~h<t< ..~. ...c.^..
&&--$,;$:%=4;$,%=23;$~=$_;++$i==1?++$,:_;}__END__#....>>e>r^..>l^...>k^..

Thomas Kratz wrote:
> Sorry, diffed the wrong file:
>
> make that:
>
> +    $ED_OBJECT->deiconify;
>
> That does it for me with your original example.

Many thanks Thomas, I now have my ErrorDialogs functionality back. The
operation is slightly different since the trace dialog appears all the time
but I can't complain since it's no longer fundamentally broken!

How will such a patch make it back into the source package?

Regards,
Michael (msemtd).

msemtd@yahoo.co.uk wrote:

> Thomas Kratz wrote:
> 
>
>
> Many thanks Thomas, I now have my ErrorDialogs functionality back. The
> operation is slightly different since the trace dialog appears all the tim
e
> but I can't complain since it's no longer fundamentally broken!

Ah, I have never used Tk::ErrorDialog before, so I didn't notice that the
trace dialog is configurable.

>
> How will such a patch make it back into the source package?

Because of the above I don't consider this to be a patch that should be
applied permanently. It seems merely to be a workaround.
Someone with a better understanding of how things *should* work, should
have a look at it.

I will file a bug report on

http://rt.cpan.org/NoAuth/Bugs.html?Dist=Tk

Thomas

--
open STDIN,"<&DATA";$=+=14;$%=50;while($_=(s( #J~.> a>n~>>e~.......>r.
STDIN,$:*$=+$,+$%,0),getc)){/\./&&last;/\w| /&&( #.u.t.^..oP..r.>h>a~.e..
print,$_=$~);/~/&&++$:;/\^/&&--$:;/>/&&++$,;/</  #.>s^~h<t< ..~. ...c.^..
&&--$,;$:%=4;$,%=23;$~=$_;++$i==1?++$,:_;}__END__#....>>e>r^..>l^...>k^..