> > My VFUG (& CFFUG) lecture on Intro to OOPs (sounds funny doesn't it? (s)) is posted online in the VFUG Lecture area. > > Discussion of this lecture will be Friday, October 27th at 3:00 PM EST (the normal UT conference time). (Or 19:00 GMT). All are invited. > Is that 'all' like in 'tout le monde?'. You did not think that I would let pass this one, now did you ... BTW, at friday 19:00 GMT (how very cosmopolitan of you to have mentioned it) my provider it is out of bandwidth, so you will have to hear me out now. OK. Seriously. Lucien, I hope that you are in shape. First let me recognize the outstanding quality of your lecture. It is clear and easy to read, and to understand. You give a fair overview of what OOP is. That being said, there are a few assertments that you make and with which I disagree. I think they are misleading and they are not sustained in any way, shape or form by your lecture. 1. That we should forget everything we knew in FP2.x. 2. That to understand and implement OOP is a prerequisite (did you not use the word madatory?) to work with VFP, and that it would be the first thing to do when learning it. On the first assertion let me say this: I think it is simply impossible to master VFP without a good to expert knowledge of FP2.x. And I am saying that the least amount of bugs can be found in the area's that were inherited from FP. About the second assertion, I think you mix two concepts: Event drivenness and Object Orientation. Every language that supports Windows programming is Event driven. And 'Event Driving' is what you should learn first when trying to learn to program in the Windows environment. But this is true as well for Visual Basic, for Excell, and even for FPW2.6 and FPD26 to a certain extent. This does not make these programming languages OOP. It has been (1) the harnassing of the less than satifactory way in which the Windows API was implemented in VFP, (2) the lack of a decent documentation and (3) the unreasonable amount of bugs, that gave us such a hard time mastering VFP, not OOP. What forced us most to rethink our methodology, is that the READ statement disappeared from modal forms, together with it, ability to use variables scoped to this form. Not that I regret this READ statement, do not get me wrong, but this change has very little to do with OOP, and it did not help us to be able to abstract, encapsulate, apply inheritance or what have you. VFP does posess some nice OOP features. In fact it does make sense to use them, but as I argued in another thread, their applicability is limited to domains where VFP (as Foxpro before) already has such a wealth of features, that it would be foolish to introduce even more code where there is already too much. The real key to OOP in VFP is the construction of a framework, about which you are surprisingly silent BTW. I guess that it is because it is not quite ready to be published... It would take another application or two or three to be really good, and starting to deliver its promises, like reuse, RAD, etc. In 1998? Is that still within the lifetime of this framework? I doubt it. My 2 BEF. Your (not so?) silent admirer, Marc