Thanks for the comment. The colleague originally working on this function already posted a question regarding the possibility to call a Perl subroutine from $int->Eval(); on the tcltk@perl.org group. It seems it is possible to run Perl code from within $int->Eval(); with the Tcl command ::perl::Eval, however not a Perl subroutine that lives outside the $int->Eval();. Since I have 0 knowledge of Tcl and no experience in "language bridging", I was hoping to solve the issue simply by monitoring the change in the Listbox state/values. There are a couple of suggestion in other answers here that I am now examining.

I dug around the TCL interface some and was astonished to find some of the neat things it can do.

If you look inside the TCL download https://cpan.metacpan.org/authors/id/V/VK/VKON/Tcl-1.27.tar.gz you will find in the t subdirectory set-callback.t (which can be inspected via https://fastapi.metacpan.org/source/VKON/Tcl-1.27/t/set-callback.t). This exposes a method to create a program in the perl environment and "link" it to a name that TCL can call directly.

The original code posted in this thread is in Tk because I want(ed) to find a solution to my proposed approach - which is indipendent to Tcl.
TK runs under TCL, there is nothing you do in TK that is independent from TCL.When you said $int->Eval(); you were invoking TCL.

There is another way as well. https://fastapi.metacpan.org/source/VKON/Tcl-1.27/t/createcmd.t, that is createcmd.t from the same t subdirectory.

Some addition to the relation Tk/Perl/Tcl:

• Perl/Tk is a ported version of Tk which is independent from Tcl. In fact, you simply install it from cpan, with no need of a Tcl installation.
• On the contrary, Tcl::Tk and Tcl::pTk use a real installation of Tcl/Tk present on the machine. The bridge Perl to Tcl (and vice versa) is done by the Tcl module which is a required dependency of both modules mentioned before. Both modules are similar, being Tcl::pTk more focused on using a syntax which is 1=1 to Perl/Tk (in fact you can run Perl/Tk applications with no or minimal adaptation)

On a side note: if Perl/Tk is a fantastic module for out-of-the-box UI projects, the advantages of using Tcl::Tk or Tcl::pTk are:

• You use with Perl the real Tcl/Tk. This allows to use the latest release, which is continuously updated (for example to accommodate the latest macOS features).
• It allows deployment on macOS (Catalina too) with native widgets and macOS look&feel (Tk on macOS requires X11 installed, and looks "very old"). UI looks modern both on Windows and on macOS. I guess the same applies to Linux too.

I 've started to write an extensive guide on how to deploy modern Perl+Tcl/Tk application for Windows and macOS (setup/coding/packaging/code signing/etc.). I will post here a link when I am finished (in some weeks time). Maybe somebody will find it useful.

What a joy! This solves our problem at the root(not the topic of the thread) in a much better way than I hoped. To call a Perl subroutine from within the Tcl code is very simple (the Tcl is really great indeed!):

use Tcl::Tk;

my $mw = MainWindow;
my $int = $mw->interp;
$int->CreateCommand("MySubroutine", \&MySubroutine);
$int->Eval();

sub MySubroutine{
...
}

Mainloop;
[download]

TK runs under TCL, there is nothing you do in TK that is independent from TCL.

While the questioner turns out to be using Tcl, there is also a Tk module on CPAN that bundles a modified Tk (called "pTk") that is not dependent on Tcl. There was some confusion here because the questioner did not mention that he was using Tcl::Tk and I assumed that he was using Tk.