>I should also add, keep in mind that sometimes the fundamental problem with the thing you are trying to fix is that there was a design flaw built into the way the original guy attacked the problem and that is why he never got it to quite work.
>
>Instead of just concentrating on a path to fix *his* code, step back for a minute and ask yourself to define what the problem was he was trying to solve and you may see you have to unravel a little of his approach to fix the fundamental flaw in the design.
>

If we want to go to some details, I may need to post some screen shots of how the form looks like and what it does. The problem is quite ambitious and I am not sure how would I solve it if I will be presented with it myself. I bet it took the original guy a lot of time to write such interface.

It is very possible (I am almost certain) that this design was buggy from the beginning. There were also some complexities added afterwards.

But up today I spent almost 4 working days looking at that code, running and testing that form and making some changes hoping they fix the issue. They fix one problem, but a new one immediately shows up.

I already changed a lot of code. I didn't do frequent checkouts, but I did check out what I currently have. My problem right now is that I am not sure I can fix what I have so far without, for example, switching to BindEvent from GridHitTest approach. But if I attempt to do that, it may take me few more days. And this is only one version, I may still need to later fix the previous version of software we currently have in production.