in reply to Re^2: Use of break in Tkx
in thread Use of break in Tkx

Yes I'm slowly seeing that... I just modified the callback to subdue the error and break in the forms I've tried isn't "doing" it. Thanks for the advice 
sub custom_error_handler {} #just supresses error

sub cb_entry {
    my $win=$_[0]; 
    eval {
        $mw->g_wm_title("this is $win m8"); #this works ok
        #NONE OF THESE DO ANYTHING
        Tkx::break();
        $win->break;
        Tkx::break(".e");
    };
    custom_error_handler($@) if $@;
}

[download]

Replies are listed 'Best First'.
Re^4: Use of break in Tkx
by Anonymous Monk on Oct 04, 2015 at 02:28 UTC
    Try next;
[reply]
[d/l]
      Yes "next" did the trick. Thank you very much indeed! I lack the visibility to see how "next" is a replacement for "break" i.e. "last" seems a far more more natural replacement to end a loop. "last" certainly stopped any more bindtags being looked at but also took the interpreter out at the same time suggesting that the loop is the main message loop. It never occured to me to try and continue that loop. Once again thanks. BTW is there a best place/file I should be looking at to get your level of understanding re Tkx?
[reply]

        I lack the visibility to see how "next" is a replacement for "break" i.e. "last" seems a far more more natural replacement to end a loop. "last" certainly stopped any more bindtags being looked at but also took the interpreter out at the same time suggesting that the loop is the main message loop. It never occured to me to try and continue that loop.

        Its a tcl mistake, there should have been an actual Tk API call to break the chain, thats how all the other GUI toolkits do it; what Tk team chose to do was peek behind the curtain ... and then Tkx.pm guys didn't catch this corner case like other guys did

        For example, this is how the other guys handle it http://grep.cpan.me/?q=_TK_BREAK_

        Read more... (1061 Bytes)

        Where does Tkx stick it? I dare not look :) bored with that one

        But I do remember that you can always write stuff in tcl, unofficially  Tkx::eval('tcl source code');

        Once again thanks. BTW is there a best place/file I should be looking at to get your level of understanding re Tkx?

        Perlmonks? :)

        Maybe this list archived at http://www.nntp.perl.org/group/perl.tcltk/?

        Seriously though, you just about have all my secrets ... all GUIs work like this , one event loop that calls stuff... peek at the perl sources to see holes/opportunities ... super search for author [zentara][Anonymous Monk] to find an example ... write a short test case and then bug the maintainer ... repeat

        pretty much everything is possible, its just a matter of how much blind poking you want to do, the more things are used the less holes they have...

        tk tips like this... tk scoping issue, tk closures people, Re: TK Submenus (Tk::Menu , global variables/ spirit of strict), tk scoping function argument passing, can't share Tk mainwondow between threads

[reply]
[d/l]
[select]
      Not sure if my response showed up as linked with the suggestion to try "next" and further help so I'm posting it again here... Your solution and further response helps a lot and as a result you have motivated me to press on with Tkx as the concept of it being a thin wrapper giving almost direct access to TK is a compelling one. >you can always write stuff in tcl, unofficially Tkx::eval('tcl source code'); That looks like a real life-saver in these sort of situations 'cos the documentation re Tk is ok. All in all...very grateful to you. Thank you!
[reply]

In Section Seekers of Perl Wisdom