Telling tables what their fields are

Ed Kleban Ed at Kleban.com
Fri Nov 18 22:47:42 CST 2005




On 11/18/05 4:54 PM, "Ed Kleban" <Ed at kleban.com> wrote:

> 
> 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" )
> 
> 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.  
> 
> Thus inquries such as:
> 
>     mfBornDate.Table returns what?   Nil I suppose.
> 
> 
> 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
> 

Actaully, this appears to have problems.  It would work for a VDate perhaps,
but not for a subclass of VDate.  Unfortunately there doesn't appear to be
any way to associate a created field with it's table  in a manner that will
be reflected by examining the Table through API calls unless the table is
created in the API, that correct?

There's a similar circumstance it appears for creating VTables as local
properties in a VDatabase constructor using "new VTableSubclass".  The
tables don't get assigned either a name or a database in a manner visible
through the Vtable.Name and Vtable.DataBase properties.  At least the former
is r/w but the latter is r/o.

Doesn't the table need to know its database and/or vice versa for things to
work consistently? -- or is it just for use in the case where you're using a
tool like VS to open and  examine the schema structure to permit viewing of
the database with an external tool?

If I'm interpreting this right, then if you choose to use the classes way as
shown in the examples then your database structure isn't sufficiently whole
for tools such as VS to view and navigate it.  Is that correct?  Is that
desirable?  It there a workaround?

--Ed

> 
> Is there anything wrong with this approach?
> 
> Thanks!
> --Ed
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina




More information about the Valentina mailing list