Technical terms used in reference to VFP 3

[A Beginner]

What are member objects?
Reference: 'advanced object oriented programming with visual foxpro 6.0 By Egger M., Rubel M. Page 31'
Excerpt:
"All FoxPro base classes support the constructor and destructor events. However, some classes feature other events in addition to the regular constructor. Form classes, for instance, have a Load event that fires even before the Init. This particular event allows changing settings or opening tables that are needed by member objects. Doing so in the Init would be too late, because member objects that are linked to data would have already failed to instantiate at that point.

 

[Scott24x7]

Member objects are objects that are contained within the form.

So things like grids, combo boxes, text boxes are "Members" of the "Form" <whatever form>. So that their data is loaded correctly (in those cases where you are doing stuff before it appears), the .LOAD event lets you do some processing before the form's INIT event, where all the objects on the form get populated.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[A Beginner]

Objects those are on the form....?

 

[Scott24x7]

If you're building your application using the visual environment (i.e. not "pure code only"), any object you place into the form is a member of that form.
If you put a container on the form, and then put say, a button in the container, the button is a member of the container, which is a member of the form.

If you're doing this all in code, the same is true, it's just harder to visual, but when you build and run the form, then the objects in your form are members of that form.

Members could also be contained in a custom or container class, either visually or programmatically.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[A Beginner]

If you put a container on the form, and then put say, a button in the container, the button is a member of the container, which is a member of the form.

You recognized my next question would be 'what is container object?'
Thank you for the wise answer.

 

[Mike Lewis]

Be careful. There are two meanings to "container object".

A container is any object that can contain another object. So a form is a container. And so is a grid - because it contains columns. And a pageframe contains pages. And a page contains labels, textboxes, etc. And so on. But a label is not a container, for example.

But there is also a particular Container object (or, more exactly, a Container class - and note the capital C). It is one of the native classes, and its only function is to contain other objects. It's quite useful when building generic controls. For example, if you want to extend the Image class so that it can show a caption, you could place an Image and a Label in a Container. You could then treat the resulting entity as a new class, with its own properties and methods, and the ability to be placed on a form.

Hope this makes sense.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[A Beginner]

Yes, it makes. Thank you Mike.

 

[Olaf Doschke]

Notice, in this context (in the context of the text you quote) member object really just means an inner object, like the controls on a form, or within a page of a pageframe, etc. so the containership of VFP controls plays a role here. AMEMBERS() is a function returning an array of member objects, objects having member objects also have a .OBJJECTS collection as one of their properties.

This term later is introduced as a more strict definition of objects, which only applies to certain controls, eg columns are member objects of a grid, pages of a pageframe, which since VFP8 (I think) allow class definitions of these subobjects, which you could not do previous to VFP8.

I just add this, because when you ever come accross this term in the context of grids and pageframes and other controls I forgot to mention, it might have to do with their memberclass and memberclasslibrary properties and the individualisation and typisation of their inner members.

Bye, Olaf.

 

[A Beginner]

Q2. Besides defineing the scope of the Class Definition What else is special about NewObject() in contrast to CreateObject()?

Reference:

http://flylib.com/books/en/2.340.1.13/1/

"Using NewObject(), Visual FoxPro makes sure the class definition is in scope. You can specify visual class libraries (VCX) as well as PRG files. Also, NewObject() allows you to specify a compiled application that hosts the class definition. This allows you to create class libraries that are distributed in compiled versions rather than in source code."

 

[A Beginner]

member object really just means an inner object

Sharp and clear cut definition. Thank you.

 

[A Beginner]

Newobjects() can be used to add objects beside creating new object.

 

[Olaf Doschke]

Well, yes and no, there is NEWOBJECT as standalone function parallel to the CREATEOBJECT function, and there are ADDOBJECT and NEWOBJECT methods of base classes being a container to new objects.

The methods both act in adding the created object as child object, while the functions create a new root object, you can also have classes, which are intended to be child objects as standalone object, eg create a standalone container not part of a form or a cursoradapter not part of a datasession.

The NEWOBJECT variants differ from the CREATE/ADDOBJECT in their different parameterization allowing you to specify from where to take the class definition exactly, while the CREATE/ADDOBJECT miss these parameters and find the class definition by it either being a native baseclass or be made known by SET CLASSLIB and/or SET PROCEDURE.

Only making use of the "shorthand" CREATEOBNJECT/ADDOBJECT functions you need less coding but need to pay attention to never have two classes with same name, or you can't guarantee what is used. With NEWOBJECT you can make the distinction of two same named classes by their different location. It obviously is impossible to have to same named classes in to same named files in the same path.

That said it is a good practice not to have same named classes and rather make use of SET CLASSLIB and CREATEOBJECT/ADDOBJECT, but especially the ability to let NEWOBJECT specify a library within an EXE or APP can make it a very nice tool of using an APP as class library just like a DLL can be a OLE class library without making classes OLEPUBLIC.

So the main distinction is specifying the location of the class, not the containership.

There is one other function, that can add to an object not being a method of that object, that is the ADDPROPERTY() function. It takes the object to extend as first parameter. That's most useful for objects, that are created by SCATTER or based on the EMPTY class, as they themselves only have proeprties and no methods or events. But there isn't something alike for objects, eg ADDOBJECT() does only exist as method, not as function taking in an object as parameter.

Bye, Olaf.

 

[A Beginner]

There is one other function, that can add to an object not being a method of that object, that is the ADDPROPERTY() function. It takes the object to extend as first parameter. That's most useful for objects, that are created by SCATTER or based on the EMPTY class, as they themselves only have proeprties and no methods or events

You stated lot many things in that small paragraph. Please don't be that concise, I am a beginner yet.
In the book of M. Egger also I studied just a few lines about Scatter Name command.
Please elaborate it. In order to put it separately I make it my next question
Q3. what are data objects? How Scatter Name and gather name is used to handle them?
Can data objects be used always in place of regular data? Can they be placed in database? many such questions cropping up into my mind?
Mr. M. Egger writes "Using data objects has many advantages over using regular data. You can access multiple records at a time using multiple data objects. Also, data can be handed over to other objects, even across data sessions and through OLE connections." Please guide me on that point of view.

 

[Olaf Doschke]

Well, yes, make that a new question, I'll answer it there.

In short here: data objects are not the better way to represent data. We have SAVE TO (yet another new command) which can save variables into files or a memo field, but that excludes objects. Gathering data objects to where they came from: records. So DBFs with same schema of fields is what stores them, so DBFs are still our tables. And since controls don't bind to data objects, their use as frontend data is limited.

What Markus Egger writes is all true, yes. In what way do you need more elaborate explanations of what he says? He also says a lot of things, but each of them is simple.

Take that into account, when you write the first post of your new thread.

I only meantioned the ADDPROPERTY function, as it completes the set of things surrounding CREATEOBJECT. Because when you start talking about child/member objects, you should also learn about how to add properties. You're distracting yourself, if you now follow the route of data objects, though, it is only related becuase the function ADDPROPERTY only makes sense knowing there are dumb objects not having any methods and events, while you first need an object to add a property to it. This is rather a weakness in that in VFP not everything is an object, as in many other newer languages. Our simple types really are just simple types. That makes some functions necessary, that can work from outside.

Bye, Olaf.

 

[A Beginner]

Thank you all for the pointers.