Telling tables what their fields are

[Ruslan Zasukhin]

On 11/19/05 12:54 AM, "Ed Kleban" <Ed at Kleban.com> wrote:

Hi Ed,
 
> All of the Classes_way examples declare properties of the appropriate VField
> subclass, and then have a constructor method that employs a constructor for
> each field using a form such as:
> 
>     mfBornDate = new VDate( "fldBornDate" )

right
 
> As a result, you can access the VField methods for a table using the VTable
> subclass properties, but not by using any of the VTable methods, since at
> the VTable class level, the code is clues of what fields may have been
> defined.  

Right, and THIS IS the main advantage of Class way
 
    * you avoid a lots lines in your code as
        Table.Field( "xxxx" )
        
      so this affect performance.

> Thus inquries such as:
> 
>     mfBornDate.Table returns what?   Nil I suppose.

No of course. :-)

It returns Table where you have create fields.
How it works?

Constructor of Vtable work BEFORE start work constructors of fields,
So in background it set one global pointer. (inside of plugin)

> This can presumably be fixed by instead declaring the new VField instances
> using something like:
> 
>     mfBornDate = self.CreateDateField( "fldBornDate" )
> 
> which would then allow you to successfully use inquiries such as:
>     
>     mfBornDate.Table
> 
> Is there anything wrong with this approach?

STOP STOP STOP.

You guess or you really see that .Table  returns nil ????

It should work correctly.



-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]