>Is this the Dapfor.net.ui ?
>
>I've spent a lot of my career doing project rescue - i.e. trying to figure out some code that never quite worked written by some guy who is now in hiding ;-) It is easy to get to a point where you realize the path you have been going down trying to fix his stuff isn't working. That means you understand the problem better now than you did at first.
>
>Sometimes the fastest way to get to a better place is to roll back to where it was when you took it over and rethink your design assumptions about how to fix it, knowing what you know now.
>
>Releasing something you know has problems or that isn't really a solution is not a good idea and if you haven't fixed it at this point it is probably because there was a better path to a solution.

No, it's not Dapfor.net.ui (not sure what it is and haven't checked).

This is an inventory retail screen that uses some compex class with lots of code and is called from quite complex form and it also calls another form.

There is a dynamically populated grid and a container above which is used to pass double click around using GridHitTest method. I am not exactly sure why such complex code is used and not, for example, BindEvent double click to class method code. May be at the time it was written BindEvent didn't exist.

Re-writting to use BindEvent can be quite a challenge. But GridHitTest seems to have its own problems. Sometimes I double-click on one place in the grid and the cell value changes to the value in the first row in the same column of that grid. I am not sure why is that and how to fix it.

Do you think I should try to get rid of the GridHitTest and attempt to re-write with BindEvent?