>>Full ACK on the need to identify the cause. But stripping own code away on a foreign control is a sound idea, as it eliminates (in this case as well) code not responsible for the misbehaviour. Going in and adding code before trying out new other controls and having a valid map of what is working and what not is not something I would do - so your key phrase is correct.
>
>I am not sure how was I supposed to debug the issue with ngGrid (having originally only min version of the js file in the project). I can see that my code was correctly executing, but I never saw any of ngGrid code executing at all and tracing through all the angular code that runs is almost impossible.
>
>So, if you can suggest some debugging techniques for this kind of a problem with third party control, it would be nice.

asking without throwing pagination in would be one option if averse to logging

>
>I also have unrelated question. What is the difference between declaring
>
>var SomeVar
>
>vs.
>
>$scope.SomeVar
>
>and when should I use one over the other if I only need that variable, say, in defining cellTemplate?
>
>Thanks in advance.

var stops the variable from being a global and restricts scope to the function issued in.
global being something, which is closest to public in vfp.

second should be adding/overwriting a (new?) property to $scope