NET to create and use objects at a fundamental level. Armed with this knowledge, you should be able to transfer it from VFP to. This included a broad over-view in the first article, and an in-depth look at creating methods and properties in the second article.
In our articles in the November and December 2003 issues, we discussed the fundamentals of object-oriented development, comparing how they're implemented in VFP and. NET, you'll find you have a head start when it comes to inheritance.
VFP DEFINE CLASS CODE
We will probably translate the Customer DOT FieldName syntax to code that will resolve this at runtime (or throw a runtime error when there is no cursor or variable with the name "Customer".If you're starting to work with Visual Studio.
The customer->FieldName syntax does not have that problem, because the ALIAS (->) operator is only used for memvars and fields and never for properties. M-dot - can be both a local and a dynamic variableĬustomer.FieldName can be a field in a workarea/cursor named customer, but also be the FieldName property of a (undeclared?) variable named customer.Įspecially the last one is difficult to resolve at compiler time because both the undeclared variable as well as the workarea can be created/opened outside of the scope of the current function / method. In general, we have a potential problem with the use of Dotted names in FoxPro, which is sometimes very ambiguous: In other words: M-dot means that something is NOT a field. At this moment only M-> works and indicates that the identifier following the ALIAS (->) operator is a dynamic memory variable.įrom what I have seen FoxPro uses m-dot both for dynamic variables as well as LOCAL variables. Identiers that are not declared as FIELD, MEMVAR or LOCAL are assumed to be instance fields or properties of the class (or STATIC/CLASS level properties). Likewise if you declare memory variables with MEMVAR or initialize then with PUBLIC or PRIVATE then the identifiers will be mapped to dynamic memory variables. synax then identifiers will be seen as field name. If you declare fields with the FIELD FirstName, Lastname. Please Log in or Create an account to join the conversation. Was this on purpose? In VFP, this would generate Private variables and left the object's properties untouched.Īgain: it's a great and inspiring job. In the cases of your example, FullName in Person class, and AddressBlock in the Address class would require a proper declaration.Īll user-defined properties, as well as most of the base properties, may have accompanying _Access and _Assign methods, which basically should function as setters and getters destined to override the built-in ones.įor now, two and a half questions (that may already have been addressed elsewhere, probably):ġ) Must properties be declared before their initialization? And what's the execution context of the initialization?Ģ) You skipped the This prefix when referencing FirstName and LastName in the Init method of Person.
In VFP, the _Access methods (which are events, actually) require the declaration of the associated property. This looks fantastic and promising, Robert. Net properties that read/write from the name value collection. This code uses a Custom class in the X# runtime that contains Name/Value pairs for the properties. Init event handler gets called after object has been created.
VFP DEFINE CLASS ZIP
RETURN This.Street+CRLF+This.Zip+" "+This.CityĪDD OBJECT Address AS Address WITH Street = "Main Street 1", ZIP = "12345", City = "Phoenix" Possible (optional) modifiers are PUBLIC, PROTECT, HIDDEN, INTERNALįUNCTION AddressBlock_Access AS STRING // Access method PUBLIC Street, Zip, City as STRING // note that we have added the AS Type clause, OPerson := CreateObject("Person", "Fabrice","Foray") VFP compatible object creation, Checks for type at runtime