in reply to Re^2: A question on using Tk::ItemStyle in Tk::Tree
in thread A question on using Tk::ItemStyle in Tk::Tree

Tk::after
لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
  • Comment on Re^3: A question on using Tk::ItemStyle in Tk::Tree

Replies are listed 'Best First'.
Re^4: A question on using Tk::ItemStyle in Tk::Tree
by Anonymous Monk on Nov 01, 2014 at 09:49 UTC
    choroba,

    Thanks for pointing me to this Tk::after. However, I must honestly admit that I'm having difficulty in understanding the docs.

    Firstly, the after method has only two forms.
    1. after(*ms)
    2. after(*ms,*callback)
        In both forms the first parameter is time delay and this should be specified in milliseconds. But Khen1950fx's construct specifies a string 'idle'

        Secondly, the second parameter is the callback whose execution has to be delayed. But in Khen1950fx's construct the method after is called on an instance of MainWindow and does not specify any name of the callback method whose execution is to be delayed.

    But fundamentally speaking though, how does delaying the execution of a callback get helpful?

    I'm unable to find any other docs on this. So please let me know. Thanks in advance

      choroba will likely come along with some more details for you, but maybe this will suffice for now, given:

      $mw->after( 'idle', [ configure => $styleref_select_parent, -background => 'cyan' ], );

      Even though it could be made more clear, we do see in the Internal Details documentation:

      $time is the string 'idle', representing an idle queue timer, or a integer millisecond value.

      If you never wanted to use that idle string anomaly, there is an ->afterIdle method. The equivalent of the above could be coded:

      $mw->afterIdle([ configure => $styleref_select_parent, -background => +'cyan' ]);

      The See Also links to Tk::callbacks where it shows the valid ways to specify a callback, one of which is:

      [ 'methodname', args... ], ...

      So going back to the sample from Khen1950fx, we see that he passes 'configure', as the method name, and $styleref_select_parent as the object reference that will be passed as the first argument to Tk::ItemStyle::configure, along with the with arguments to change the background color. Incidentally, the fact that after() method is attached to the "$mw" object means that the timer will be cancelled if the MainWindow is destroyed before it fires.

      Here's one last example, that shows the square brackets turn out to be optional in this case, as well. After two seconds, set the entire background color:

      $mw->after( 2000 => configure => $tree, -background => 'green' );

            I was waiting and hoping if choroba would also respond. Anyway, this kind of detailed response from you does help for newbie like me. I had to repeatedly read through your response and hence it took me sometime to go through the after call details you specified.

        1. Now it appears to me that this afterIdle construct,
          $mw->after( 'idle', [configure => $styleref_select_parent, -background => 'cyan' ], );
          in this particular scenario can be replaced by:

           $styleref_select_parent->configure(-background => 'cyan');
          Is my observation correct ?(after all I got the same output) If not, is there any advantage in going for a Tk::After call?

        2. Refering to your last example: As per the docs,

          (on Tk::Callbacks) the callback when using methodname has the syntax,

               ... => ['methodname', args... ] ...

          and the Tk::after method has the syntax
          after(*ms*, *callback*?).
          So how do these fit in to permit the syntax  2000=> configure => $tree
          in your code:
          $mw->after( 2000 => configure => $tree, -background => 'green' ); ?

        3. I'm eagerly trying to get a handle in understanding this afterIdle method. So I chanced to come across the problem Table matrix suspected selected cell discrepancy and the solution to it Tablematrix 'odd' behaviour of mouse and key solved. where the method
          sub brscmd { my ($previous_index, $actual_index) = @_; my ($row, $col) = split ',', $actual_index; my ($sel, $js); $sel = $t->curselection(); # <-- THE PROBLEM print "@$sel\n"; foreach $js (@$sel) { print "\n[brscmd] actual index <$actual_index> from curselection <$js>\n"; } }
          was replaced by
          sub brscmd { my ($previous_index, $actual_index) = @_; my ($row, $col) = split ',', $actual_index; my ($sel, $js); $t->after( 'idle', # <-- THE SOLUTION sub{ my $sel = $t->curselection(); print "@$sel\n"; foreach $js (@$sel) { print "[brscmd] actual index <$actual_index> from curselection <$js> last_button_key <$last_button_key>\n"; } } ); }
          and things just happen to work fine.

          But I'm unable to grasp the idea behind using  afterIdle call here.

        4. I realize that the number of monks responding to questions on Perl/Tk is generally less than what is comes to other areas of Perl. Since last week the count is again down by 1 after very useful zentara bid adieu to PM.

          So any information monks provide, I say sincerely, will be useful indeed.
          Many Thanks