>Hi Naomi,
>
>>Also in this case most of the screens are dependent on each other.
>
>This app needs refactoring. Refactoring on this level only works when you keep working on the project for a longer period (months or years) and keep evolving it. If your job is to just do some fixes as quickly as possible, refactoring is out of question.
>
>If you only have limited time and there's active no development on this app except for a few "quick" bug fixes, then you can only patch the application. You might be able to fix these bugs, you might introduce new ones... I'd spell this out to the customer and minimize any liability for the result.

We have a long term relations with this customer. He came here the other day and gave us a demonstration of this project. From the way he was demonstrating its functionality it looked quite impressive.

I got several assignments on this project and then started to look into the details. Originally I was also just adding little things.

Then I got sort of enhancement request, that lead to a slight re-design of database model + creation of quite a complex form. Complex for me, because I had to learn a framework a bit, develop a mover class for this project (even though I utilized most of the existing code), then create a CA, etc.

This particular form works great now and also I fit it into the main form using the minimal approach (just instead of the original direct searching in the table I created a cursor at the load of the form with the similar structure / index, so the existing code works).

However, fixing the bugs I sort of postponed. With another developer here we discovered (we think) the cause of one severe problem, which is probably a cause for a few bugs in my list.

However, how to exactly fix this particular screen - is not clear to me. The screen is very complex and called from various modes with different parameters that dictate the filter used.