Exactly, these things are like 'cookies & fudge' ice cream. If you've never had it, you don't know what your missing! But when you program in multiple languages, sometimes fox starts looking a little vanilla.

I didn't even realize the possibilities until you mentioned the refresh problems and ActiveX compatibility. All the 'house of cards' programming we do to get the UI stable could be greatly reduced!

>>2) I like the structure class workaround, but for true API interfaces, I
>>need callback capability and addressof like VB or C. Even the clunky way we have to just get Hwnd, why not make it a property of the form? There was another suggestion of providing controls that are true windows subclasses, with the Hwnd and everything available. These controls could exist in addition to the standard bitmapped controls for backward compatibility. To help phase out the bitmapping of forms without breaking backward compatibility.
>>What do you think?
>>
>
>Hi Ed,
>
>PMFJI, but this one particular item caught my attention< g >.
>
>Before I get to this, however, I'll agree that being able to create a structure using native commands would be nice for dealing with the API.
>
>A lot depends on whether or not we'll get this in the next version or ever. VFP's memory management scheme is what's at the heart of this. In order to achieve the performance it does, it moves memory around a lot. This makes it difficult to implement callbacks, use native windows controls etc. The biggest downside of implementing this could be that we'd have to sacrifice in the area of performance when manipulating tables. If this was the case, my response would be, "No! Don't do it!" This is VFP's area of strength and it shouldn't be sacrificed, especially when other tools exist to do the job.
>
>However, I would be remiss if I didn't point out what some of the positives would be.
>
>1.) VFP could dump the current way it handles windows messages, meaning less code to be maintained by MS and possibly resulting in a smaller run time DLL. This would also mean that certain problems with windows properly being refreshed would disappear.
>
>2.) Would allow the use of VFP with automated testing programs.
>
>3.) Would provide for better and more reliable interaction with ActiveX controls.
>
>4.) Would reduce the necessity to document problems caused by the way messages are handled by VFP.
>
>5.) Performance in the visual area (forms) should improve.
>
>Since the next version was demo'd at DevCon under Win2K, which is a 64 bit OS, it may be that the product will be 64 bit. If so, it would mean that major changes were/are implemented in order to interface with the new API (new functions, data types, structures, etc.). As I've said several times before, if this is going to happen, this would be the time for it to happen.
>
>If it doesn't happen, my take on it would be that the performance necessary in data handling couldn't be achieved to make it worthwhile. End of story. It doesn't mean that we were ignored or anything else. I don't think that any additional clamoring by us can make this happen. There are simply too many benefits from implementing this for it not to be done, if it can be.