How about crunching this down to a short 10 line sample that reproduces the problem, that doesn't depend on a whole pile of context that we can't see and doesn't require external file access? <grummpymode>There's about a 99% chance that you will find the problem yourself in the process, but that's the price you pay for focusing on the issue rather than getting us to trawl through the code for you.</grummpymode>

Yeah, I know. I was up to my armpits in this problem and had to rush out the door for a meeting and some other stuff and wanted to get it out there to hopefully get some clues by the time I got back! Pretty presumptuous of me I know.

Penitently, jdtoronto

    -textvariable => \$::cini_global->{trickle}->{email_template_file}
[download]

Is this a reference? is $cini_global a hash reference? Is the value that falls out the dereferencing chain a reference?

$::cini_global->{trickle}->{email_template_file} = $self->{_nb}->getOp
+enFile(-filetypes => \@types );
[download]

Having these questions answered, the solution to the problem may be simple ;-)

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

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]

Rob

From your statement the file is getting updated the display just isn't.

The problem is not with textvariable. I had this same problem. I had to redraw the screen after another call to the import file. So I would suggest after you make the change reload the import file and then redraw the screen.