>
>>- OOP menus
>
>Dubious. Here's how I feel. First, menus are pretty much application specific, so what would we gain?

If would be easier to control individual menu items. Enabled/disabled. Hidden/visible. Add a new option to a menu or remove one.

>Second, the LIFO stack implementation of VFP menus is a very powerful construct already. Third, and perhaps most telling, menus aren't even objects in VC++, they're resources.

Ahh, well, I don't know how they work there.


>
>>- More editor enhancements. I'd like to see multiple clipboards, ability to split the editor into multiple windows so I can view two or more sections of the same prg/method at the same time. Abilility to seach mulitple objects in a directory.
>
>I'd say so. Look what we've seen so far with VFP 7.0's beta.

Yes, there have been some improvements in 7.0, but there is still lots more room to make it better. In my Clipper days I used Brief, which was a fantastic editor.

>
>>- Callbacks and increased COM support.
>
>Highly doubtful on the former. VFP's internal memory management currently prohibits it. I don't know how big a deal it would be to re-write, but the guess here is major. Not that that would make it prohibitive. Afterall, look what happened to VB (or was going to). The concern here would be the performance impact. IOW, does VFP's current memory management contribute to its performance? If so, don't want it or need it.

Yup, I understand the problems in having callbacks in VFP, but I was asked what I want.

>
>As far as "...increased COM support", in what areas?

7.0 has made huge improvements here too. I'll be talking about this in my sessions in San Diego.

I have to agree with Erik in an earlier post. Collections would be nice and make some COM stuff easier. I've done the same kind of kludges that he's talking about and they aren't pretty.