>Harry
>It is interesting. My sub subclassing knowledge leads me to suspect READ EVENTS may have something to do with it. You could develop a find/replace popup that works similar to VFP's find, yet restricted to field objects.

vfp has many quirks and inconsistencies. The trouble is that we tend to blame most of our problems on these rather than (as in my case this time) our own stupidity!

>
>WHAT really interests me, as I learn more and more about how OOP may benefit my production is:
> Whats the advantage of subclassing a base class? What I do is float a textbox on the form. If I have other textboxes with similar attributes, I set the general properties and methods that will be shared, then copy and paste and rename, re-top and re-left. Why are you subclassing and could it be helpful to me?

I am new to OOP myself, and it took be a while to 'get it'. The way I see it, so far, is that subclassing offers two main advantages. First, you don't bugger up your base classes, so if you really screw things up, you can revert to those. Second, and more important, the subclasses can contain all the procedures and functions you used to put into a procedure file or separate standalone program files. What I couldn't see for many moons was the point or advantage of that.

I now see the advantage of this trick can be seen, for example, if you subclass a form which now becomes your 'base' for all other forms in an application. Lets say you want them all to have certain colours, respond to certain keystrokes, set up certain variables which control what you are doing etc etc. All this gets built into ONE form - which then becomes the basis for all your other forms and prevents much repetition. I'm in the middle of wrestling with a conversion of a major 2.6 (dos) app to vfp and I'm just beginning to wrap my head around the 'point' of doing it like this. It is not, after all, any apparent saving in space or code, as the same code that I used in the dos app is now incorporated into my forms. The most obvious benefit is 'self containment'. My new forms can run entirely on their own. They don't need to be part of any particular application. Not much use if I'm only interested in creating a single app, but, hopefully, that is a rare condition! The forms thus developed can now be used and re-used wherever I want them. And, in fact, there is a saving in space as well, because each subsequent form, although being based on a subclass and appearing to be a copy of it, isn't really! The code only appears once. (in the subclass). The only additional code is the bit that makes each new instance of the form different from each other. This is markedly different from what we are used to in procedural programming, where even if forms were based on an original, each new version required ALL its own code to make it run. Classing allows the objects to 'start' from whats gone before and then add to it just the new bits.

On the smaller scale, consider your textbox example. What you are doing will work. But it will take you much longer than simply building the desired properties into a subclassed textbox and then making that your 'base' textbox. And the real beauty of it is, if you change your mind about a particular property or method, you only have to correct it once - in the subclassed textbox - and all your form textboxes 'inherit' the changes instantly. THAT is a major benefit!

Example of how I've used it for the textbox that caused me to start this thread: I want my users to be able to clear any textbox or editbox by pressing a single key. In addition, if the textbox controlsource is a date field I want them to be able to press another key to insert today's date. By putting appropriate code into the subclassed textbox's keypress event, I made those facilities immediately available to over 1000 textboxes throughout my application. Now if that aint an aid to productivity, nothing is!

All the above is probably still a naive summary of the benefits of OOP but if I'm badly out of line, no doubt one of the gurus will step in and sort us out

HTH

Harry