>Hi, Dan-
>
>You can use the name property. But, as George pointed out, it is a native property of a custom class. All you need to change is to remove the space in the assignment. The code runs fine with that change. ("Name" cannot contain spaces.)
>
>Also, there is a difference of opinion about whether object properties should use Hungarian notation (prefixing properties with their intended type). Nigel has pointed out that some feel you should, but some of us (I'm in this camp) feel it's not appropriate/necessary for properties as it is for code. IOW, it's really up to you, but do use your convention consistently.

Hi Nancy,

So people don't think I'm totally off my rocker (which I may be< g >), I thought I'd explain my mention of using the "v" prefix.

Shortly after VFP 6.0 was released one of the things that I discovered was that if you had an object who's property names matched the names of the fields in a table, that if those properties had _Access events, that they would fire when you used GATHER NAME < objname >, and you could control the data that actually ended up in the particular field by returning the desired value from _Access.

Now I have to work with a couple of systems where I have no control over the ncoming data structure and they are, to say the least, not the best. In one case the type of order being processed is determined by one of three logical fields, rather than a single order code field. The idea occurred to me that by using objects with the appropriate _Access and _Assign methods, I could do a SCATTER NAME..., pass the resulting object as a parameter in a CREATEOBJECT() for a custom class, assign the approriate values (making changes where necessary), then later do a GATHER NAME to another table (with the correct structure) and I'd have everything translated.

Now there are a number of tables that will require this, so as a result I decided to write a code generator that would do the necessary work for me (BTW, I love to write these sort of things). Of course, the problem of fields with the same name of a property of the Custom class cropped up. The simplest solution was to use a "v" (for variant) prefix. This, of course, immediately tells me that the field has the same name as one of the normal properties, and allows me to generate the code without a lot of unnecessary overhead. Further, since part of the job of the class is to make the proper translation, Hungarian notation might be misleading, since the data type returned may or may not be the same as the original.