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;
[download]

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
[download]

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;
[download]