$variable->{"4,0"}="Test".$cnt++; Your object, $t is oblivious to the fact that one cell just changed. And you have to use brute force to make an update of the entire window happen.
$t->activate("4,0"); $t->curvalue( "Test".$cnt++ ); This works because $t is now fully aware that a cell within the %variable hash has changed and Tk will therefore update the screen automatically.
Raw performance is one reason to violate OO encapsulation. I did this in one application with often say 100,000 cells. When I say sorted by a column, I manipulated $variable directly and then called one of the methods that you correctly found will cause a full window "repaint". The internal data storage for a tablematrix object is amazingly enough, not an array or an array of hashes, but a 1D hash table. The combination of row and column are the keys. $variable->{"0,2"}="something"; #sets row 0, column 2 to "something"
Under certain circumstances, it is possible to "hide" some extra info inside the $variable which tablematrix will ignore (meaning more info than just values of the coordinates). Of course this is a massive OO encapsulation violation! I haven't needed to do that myself, but I have heard of this being done.
In your application, just call the appropriate methods on the $t object. Do not manipulate the storage of $t directly.
Update: Another comment, I see you have: -sparsearray => 0, in order to override the default of using a sparsearry. The effect of this could range from "nothing" to "a lot" in terms of the number of hash keys generated. In general, I would advise using the object's defaults and then enable stuff like this when needed and then put a comment in the code about why this was needed.
In reply to Re: TableMatrix asynch update of cells
by Marshall
in thread TableMatrix asynch update of cells
by olgo
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |