I'm suspicious of Config::IniHash myself... I'm operating under the assumption that the $cini_global is a hashRef, and I know that getOpenFile returns a scalar -- in this case a selected filename. Here's a shortened example:
use Tk;
use strict;
$::cini_global = { trickle => { email_template_file => "nothing" }};
my $mw = MainWindow->new;
$mw->Entry(
-width => 40,
-textvariable => \$::cini_global->{trickle}->{email_template_file}
)->pack(qw/-expand 1 -fill x/);
$mw->Button(
-text => "Change",
-command => sub {
$::cini_global->{trickle}->{email_template_file} =
$mw->getOpenFile();
})->pack;
MainLoop;
I suspect there's something else going on outside of the shown code. Perhaps Config::IniHash creates something different than what it appears
Update: It would seem that Config::IniHash does some pretty interesting things under the hood and isn't exactly what it seems. I haven't looked at all the code, but my guess is that the two times you use it, the internal references are different. I've added a second example that shows how I'd work around it if I had to use Config::IniHash, which I'm not certain that I would.
<crotchety voice>Config::IniHash seems a bit too clever for its own good to me</crotchety voice> Still, its code makes for pretty interesting reading ;-)
Example 2 : In the second example I was able to reprodce the reported problem. The code shows how I worked around it.
config file, containing:
[trickle]
email_template_file=nothing
Script with workaround:
use strict;
use Config::IniHash;
use Data::Dumper;
use Tk;
$::cini_global = ReadINI 'config';
my $ref = $::cini_global->{trickle}->{email_template_file};
my $mw = MainWindow->new;
$mw->Entry(
-width => 40,
-textvariable => \$ref
)->pack(qw/-expand 1 -fill x/);
$mw->Button(
-text => "Change",
-command => sub {
$ref = $mw->getOpenFile();
$::cini_global->{trickle}{email_template_file} = $ref;
})->pack;
MainLoop;
Rob
|