Books usually say that if the classes get too big to manage, rethink the implementation because it is quite possible that the design needs correction since classes have not been defined properly.
But in situations where classes are indeed big, for example when a class is being extended to implement the functionality of a control (Canvas for example), and there are many different things like hit-testing, drawing, managing the drawn items etc. Is it a good solution to use partial classes in such cases to separate 'different' things of a bigger container (such as a custom control)?
Secondly, as a more general and broader solution, what should be considered before moving to Partial classes?
Yes, if the class is naturally large, using partial classes can help you manage the source code. I've used this before now to split the tests for a single production file into several source test files. Likewise when reimplementing LINQ to Objects, I used partial classes to put each LINQ "operator" in its own file - even though they all contributed to a class called Enumerable.
Partial classes aren't a good alternative to good design though - when you can make your actual classes smaller, it's worth doing so. If you find you've got a bit class which you want to break up, partial classes can help you to refactor the big class into two smaller classes - you can divide the class into two sections without changing the functionality at all, then perform the real split in a smaller step.