tables

[Das Goravani]

Yes, if you set the sub type of a list to a table, or a schema, then that handles the definition right there. You don’t need to have any lines of code stating to define the list. If you have the assignment of the session object to the list done in the construct method of your overall table superclass, then that is done automatically also  when Omnis instantiates that table subclassed list. Everything is done when the window or form opens, or when the object instantiates.. any lists sub classed with a table will get defined during this construct period.. the table superclass construct is called if your table inherits the construct method. This all happens during construct. One construct might end up calling quite a few other constructs in other words. 

A lot of words for two really simple things. 

Tables are addicting. Once you are used to them you really miss them if you can’t use them, like when working with the Native datafile. 

Those of us who are used to them tend to do most work in them. 

I would also say avoid code classes altogether. They are a part of the old Omnis way. Or at most they are part of the Datafile way.  They are pretty useless once you are used to using only Tables and Objects as major code holders if you are doing SQL.  Some code has to be in the window or form. Meaty large pieces of code go into objects and tables nicely. 

In your naming of things, use the same name for related classes, for example, a window, a schema, a table, and an object, all for invoicing, could be:

wInvoicing
sInvoicing
tInvoicing
oInvoicing

Makes things easier to find. Be redundant with names, not creative. 

Once you are used to tables, you use them to define lists instead of schemas. Defining by a schema is fine but it does nothing additional for you. Defining by a table gets everything going.. instantiates the Table Class that is. 

Once you are using Tables a lot, or fully, you end up with blocks of code that exclusively work off the list. Like:

ilCustomers.$initializeCustomer
ilCustomers.$checkForAccount
ilCustomers.$findSalesRep

My point is, you end up with calls to Table Methods one after another, sometimes. Factually it makes the code easy to read.

It’s a beauty too to be able to just say $cinst inside a Table Class to address the list or row. This also addresses the Table Class itself, so for example if you are in it and call another method in it you can just say as in other places:

Do $cinst.$someMethod

So $cinst is the list or row and as well the table class. You get used to this. 

Omnis is adamant that Tables are slicker than Objects. With objects you are removed from the list by a level. Whereas with table classes they are the list or row. Intimately intertwined. 

Also, you can access Table Class variables outside the of the Table Class by a combo of list and var name, as like:

ilCustomers.invoiceTotal

I’ve never had occasion to do that so I feel weird saying it. 

Omnis says Table Classes are a special type of Object Class, or they are similar, but tables are nice. 

Hope this helps somewhat.