Greetings!I am interested in overriding the Resize method of Excel's Range object. Ideally, I would create an object called Range that delegated everything to a real Excel.Range object except for this one method. In a perfect world, this would be totally trasparent to the user, so they would call Range("A1").Method, and it would behave exactly as if it were an Excel.Range, except for the Resize case.I'm not sure the above scenario is possible. However, I think it should be possible to set up an extended SpecialRange object that has one procedure to delegate Range methods, ie: SpecialRange.PerformMethod(methodname:="Offset", arguments:=2). In this case, my SpecialRange object would use PerformMethod to pass the user's requested methodname as text to an Excel.Range object, which would then perform the embedded Excel method. My PerformMethod procedure would delegate all methodname strings to the Excel.Range object unless methodname:="Resize". I know it should be possible to send the method request directly to the vtable with the AddressOf operator, but I don't know how to do it in practice. Any suggestions?

MercurySchroeppel: you don't give any details why you want to do this. It sounds like a lot of work... please explain what you are trying to end up with and why!

It probably is a lot of work. Why? Hm. Strictly speaking, to satisfy my own curiousity. It would be nice to be able to provide developers at my firm with some more robust methods on various built-in Excel objects. It came up because I'm building a developer tool for Excel VBA Add-Ins.As to being able to hit the vtable with a text method call, this has come up on more than one of my projects. Here, it would be an easy way for me to extend base objects. On another project, all of our custom business objects had to be placed within a COM+ multi-tasking workflow. The workflow was great because we could run different business processes simultaneously, maintain dependencies between them and get status updates. However, the workflow also required us to impose a very complicated set of wrappers on our business objects before they could be incorporated. It would have been much easier to have one generic wrapper that passed along our custom methods as text to the workflow system. Does that make sense?

Turn on you instant messaging and I might be able to direct you to an answer.

AIM is armed and ready!

frostrom,how about sharing your wisdom with the rest of us ? Is it s state secret

No secrets. I susbscribe to a listserver for Excel development.The EXCEL-L list is hosted on a Windows NT(TM) machine running L-Soft>international's LISTSERV(R) software. For subscription/signoff info>and archives, see http://peach.ease.lsoft.com/archives/excel-l.html .There are some of best excel people I know. Excel MVP's etc. If you e-mail questions, usually a solution comes up. Although, I think there are quite a few excellent VBA guys/girls in this forum as well. I think the Excel-L list is a little more geared toward daily users of Excel doing models, automation etc. vs maybe some Wilmotters who what to do strictly development for an end user. Check it out if you wish. -Rob

Thanks for the link frostrom.P.