>>>true windows object,
>>
>>No, no, no. This will have performance penalties.
>
>Not that I am arguing for true windows objects, but I don't believe the performance argument. From my experience, VFP's UI responsiveness is not noticeably slower than VB's, and VB uses real controls. I know that the decision to use painted controls was based on performance, but a lot of things have changed since this decision was made...

Erik,

Personally, as someone who has used Fox since 1987ish I think that the interface's speed could be made faster. What I mean is the snappiness of the screens. Underneath I'd prefer to keep the engine as fast or faster if possible. Not that I'm dissatisfied but there does seem to be a slight difference in the various MSFT products here. Having said that I think that we'll get it. Look.. It's in the interest of MSFT financially to keep making these changes.

Actually... I'd like to see VFP kind of torn apart into three pieces. 1) Data engine, 2) commands we all love and 3) What the user sees.

If this could be done I could put any fron end on the product possible and tie a SQL back end into the logic (middle tier). That way all of MSFT's products could share the same menus, reports and so forth.

Of course, we pretty much have that now. The bloat won't go away but as long as the performance doesn't go down, who cares? All MS products have this bloat. VB does but spreads it out over a bunch of OCXs & DLLs.

Just my daily heretical thinking process. <g>

Best,

DD