Hi,

Thats weird, it works fine for me

What happens if you add  use Tcl::pTk::TkHijack; ?

Which versions do you have?

#!/usr/bin/perl --
use strict;
use warnings;
use Tcl::pTk;
my $int = new Tcl::pTk;
$int->Eval(<<'EOS');
# pure-tcl code to create widgets (e.g. generated by some GUI builder)
text .e
## http://wiki.tcl.tk/1626#tk_version
.e insert end "tcl_version      $tcl_version\n"
.e insert end "tcl_patchLevel   $tcl_patchLevel\n"
.e insert end "tk_version       $tk_version\n"
.e insert end "tk_patchLevel    $tk_patchLevel\n"
.e insert end "tk_library       $tk_library\n"
pack .e
EOS
my $e = $int->widget('.e');     # get .e entry into play
$e->insert( "end", "
Tcl::pTk $Tcl::pTk::VERSION
Tcl $Tcl::VERSION
\$^V $^V
\$] $]
");
$int->MainLoop;

my $mw = MainWindow->new();
my $lab = $mw->Label(-text => "Hello world")->pack;
my $btn = $mw->Button(-text => "test", -command => sub {
    $lab->configure(-text=>"[". $lab->cget('-text')."]");
})->pack;
MainLoop;

__END__
tcl_version      8.6
tcl_patchLevel   8.6b1.2
tk_version       8.6
tk_patchLevel    8.6b1.2
tk_library       C:/Tcl8.6/lib/tk8.6

Tcl::pTk 0.90
Tcl 1.02
$^V v5.16.1
$] 5.016001
[download]

Update 2019-02-26: disregard my hypothesis below; I've since figured out what the issue was and addressed it in Tcl::pTk 0.95. See my newer reply.

Howdy, I was recently added as a co-maintainer of Tcl::pTk, so I wish I had come across this question earlier.

Indeed this sounds like part of the program is trying to use Tk but Tcl::pTk::TkHijack isn't loaded. Having Tcl::pTk installed does not make Perl/Tk programs automatically use it. To summarize what's documented, using Tcl::pTk with an existing program requires (from most to least effort) either:

1. substituting all mentions of Tk with Tcl::pTk, i.e. use Tk; with use Tcl::pTk;, any Tk::package or Tk->thing with Tcl::pTk::package or Tcl::pTk->thing, etc.;
2. putting use Tcl::pTk::TkHijack; (BEFORE any existing use Tk;) at the top of the program's main script;
3. running the program's script using the -MTcl::pTk::TkHijack command-line parameter, i.e. perl -MTcl::pTk::TkHijack my_tk_program.pl.

I find the command line parameter approach the easiest for testing an entire program without changing any code; that way I can still run it with Perl/Tk for comparison or when something breaks under Tcl::pTk. The use Tcl::pTk::TkHijack; approach has the same effect, and just that line will need to be commented out to go back to Perl/Tk. Then, for programs "ready" to be run only with Tcl::pTk (i.e. Tcl::pTk doesn't break for your program) and you don't want to use Perl/Tk anymore, then the first approach might work better.

PS: I put out a new version of Tcl::pTk recently (0.93), though there isn't any changes that would affect this findINC issue. I also added Tcl::pTk to MacPorts, which uses Tcl/Tk 8.6.8. Note that macOS comes with an older version of Tcl/Tk (8.5.9 in macOS 10.13); some improvements for macOS aqua have since been added in e.g. 8.6.8.

tcl_version      8.5
tcl_patchLevel   8.5.9
tk_version       8.5
tk_patchLevel    8.5.9
tk_library       /System/Library/Frameworks/Tk.framework/Versions/8.5/
+Resources/Scripts

Tcl::pTk 0.92
Tcl 1.05
$^V v5.24.4
$] 5.024004
[download]

The Tcl version is the pre-installed version on a macOS. But I do not think it has to do with the Tcl, rather with the missing Tk module which is trying to call - as far as I understand - in the line I pointed above.

Why didnt you answer all my questions?