Font must remain in scope??

[Roode, Eric]

I just spent the past few hours debugging this.  I have narrowed down
the problem to the scope of the font object.

Here are two simple, complete test programs.

======== example 1
use Win32::GUI;

my $main = Win32::GUI::Window->new
    (
     -name   => 'Main',
     -width  => 350,
     -height => 250,
     -left   => 300,
     -top    => 200,
     -text   => 'Font test',
    );

initialize_heading($main);

$main->Show();
Win32::GUI::Dialog();

sub Main_Terminate { -1 }

sub initialize_heading
{
    my $win = shift;

    my $font = Win32::GUI::Font->new
        (
         -name   => 'Arial',
         -size   => 14,
         -italic => 1,
        );

    $win->AddLabel(-name => 'heading', -text => "Font test",
                    -width => 150, -height => 30,
                    -font => $font);
}
======== end example 1

======== example 2
use Win32::GUI;

my $main = Win32::GUI::Window->new
    (
     -name   => 'Main',
     -width  => 350,
     -height => 250,
     -left   => 300,
     -top    => 200,
     -text   => 'Font test',
    );

my $font = Win32::GUI::Font->new
    (
     -name   => 'Arial',
     -size   => 14,
     -italic => 1,
    );


initialize_heading($main);

$main->Show();
Win32::GUI::Dialog();

sub Main_Terminate { -1 }

sub initialize_heading
{
    my $win = shift;

    $win->AddLabel(-name => 'heading', -text => "Font test",
                    -width => 150, -height => 30,
                    -font => $font);
}
======== end example 2

These two examples are very similar.  The only difference is the
location of the "my $font" line.  The first example localizes the
variable to the initialize_heading subroutine.  This does not work!
When the window is displayed, the label is drawn with the wrong font.

The second example makes the font variable global to the file scope.
This example works: the label is drawn with the correct font.

Why on earth would the font variable need to be global?  How the heck is
anyone supposed to know this?  I would have assumed that the hash of
parameters to any control would have been copied into the control
object, and thus still have a nonzero reference count.  Apparently
that's not the case.  Is it ever safe to undefine or redefine a font
variable, or let it go out of scope?  Is this documented anywhere?

More importantly: Are there any other things that I don't know about
that are going to bite me if they go out of scope?

I am trying to make my initialization and setup code modular, so it can
actually be maintained, instead of one big glomp of spaghetti.  This
sort of behavior does not help.

Eric

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/

[rpnoble]

Eric;

I have always treated fonts like menus. Both must be defined before the main window is defined.  Using this method I have never had any out of scope errors.

Roode, Eric wrote:

I just spent the past few hours debugging this.  I have narrowed down
the problem to the scope of the font object.

Here are two simple, complete test programs.

======== example 1
use Win32::GUI;

my $main = Win32::GUI::Window->new
    (
     -name   => 'Main',
     -width  => 350,
     -height => 250,
     -left   => 300,
     -top    => 200,
     -text   => 'Font test',
    );

initialize_heading($main);

$main->Show();
Win32::GUI::Dialog();

sub Main_Terminate { -1 }

sub initialize_heading
{
    my $win = shift;

    my $font = Win32::GUI::Font->new
        (
         -name   => 'Arial',
         -size   => 14,
         -italic => 1,
        );

    $win->AddLabel(-name => 'heading', -text => "Font test",
                    -width => 150, -height => 30,
                    -font => $font);
}
======== end example 1

======== example 2
use Win32::GUI;

my $main = Win32::GUI::Window->new
    (
     -name   => 'Main',
     -width  => 350,
     -height => 250,
     -left   => 300,
     -top    => 200,
     -text   => 'Font test',
    );

my $font = Win32::GUI::Font->new
    (
     -name   => 'Arial',
     -size   => 14,
     -italic => 1,
    );


initialize_heading($main);

$main->Show();
Win32::GUI::Dialog();

sub Main_Terminate { -1 }

sub initialize_heading
{
    my $win = shift;

    $win->AddLabel(-name => 'heading', -text => "Font test",
                    -width => 150, -height => 30,
                    -font => $font);
}
======== end example 2

These two examples are very similar.  The only difference is the
location of the "my $font" line.  The first example localizes the
variable to the initialize_heading subroutine.  This does not work!
When the window is displayed, the label is drawn with the wrong font.

The second example makes the font variable global to the file scope.
This example works: the label is drawn with the correct font.

Why on earth would the font variable need to be global?  How the heck is
anyone supposed to know this?  I would have assumed that the hash of
parameters to any control would have been copied into the control
object, and thus still have a nonzero reference count.  Apparently
that's not the case.  Is it ever safe to undefine or redefine a font
variable, or let it go out of scope?  Is this documented anywhere?

More importantly: Are there any other things that I don't know about
that are going to bite me if they go out of scope?

I am trying to make my initialization and setup code modular, so it can
actually be maintained, instead of one big glomp of spaghetti.  This
sort of behavior does not help.

Eric

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Perl-Win32-GUI-Users mailing list
[e-mail]
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/

[Salvador Ortiz Garcia-2]

On Wed, 2008-07-23 at 15:09 -0400, Roode, Eric wrote:
> I just spent the past few hours debugging this.  I have narrowed down
> the problem to the scope of the font object.
>
Yes, known bug.
>
> More importantly: Are there any other things that I don't know about
> that are going to bite me if they go out of scope?

Out of my head:

fonts, cursors, menus, icons, bitmaps and accelerators.

> I am trying to make my initialization and setup code modular, so it can
> actually be maintained, instead of one big glomp of spaghetti.  This
> sort of behavior does not help.
>

Try to store the perl object in the container window:

sub initiaalize_heading {
  my $win = shift;
  my $font = ...;

  my $lab = $win->AddLabel(...,-font => $font);
  # Workaround for window not storing the perl object.
  $lab->{_Font} = $font; # I use the '_' prefix to avoid name
                         # clashes with children.
  ...
}





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/