Hi Alex... hopefully this is better late than never.

My first take on this is to do what Cathi suggested. But then I dredged up an old MM project where I had done my own subclass variation of cFindForm to try and remember why I had went that route in the past. In that particular situation I only needed about half the functionality of the framework's FindForm and a whole bunch of other stuff specific only to the find related lingo used in that particular app. Looking at it again, I still think I put a lot of effort into it unnecessarily, but here's how I did it when I went down the same road your on...

I'm not a fan of disabling a built in bizobj to replace with my own. I dont like the init() overhead with a kbizobj that doesnt do anything, so I always prefer to take a step back and build from scratch. That's what I did in my custom cFindForm scenario. I set up a new bizobjmodal form and duplicated everything I wanted from framework's version. Then I subclassed the built in bizobj, added my own properties & methods and was good to go. Do to the weird nature of this particular app's "find" utility, I made sure the boss knew I was breaking from a ready-made mold to meet their specific need and therefore future 'extras' wouldnt come along for the ride.

But in hindsight, I was way too rambunctious... should of prolly done this like Cathi described.