374 Form design: ObjectPAL considerations for 1-1 linked tables

VERSIONS: All

SUBJECT: eventInfo.getTarget() with linked tables

BY: BRIAN BUSHAY

Handling 1->1 linked child tables in code is one of the more difficult things to figure out. In a posting event getTarget() assigns the record uiObject to a uiobject variable/ getTarget() require the eventInfo variable from an action method.

Also it is hard to separate a posting action in a master table from its 1->1 linked child. If you have modified a field in the master table but not in the detail then recordStatus("Modified") will be true for any Uiobject that belongs to the master table and False for any Uiobject that belongs to the 1->1 detail. If you have modified a field in the 1->1 detail (or in both) then recordstatus("Modified") will be true for both.

VERSIONS: All

SUBJECT: Property TableName

BY: BERTIL ISBERG

Whenever you do something from the keyboard or through the menus, Paradox generates actions or menuActions. In action() e g you can trap the target of an event with eventInfo.getTarget(uiTarget). In the 1-1 forms, wherever the cursor is situated when you trigger an action(), uiTarget's tablename property will be the master table. self.TableName will be the Master table, but..... active.TableName will be the Detail table or the Master table depending on where the cursor is.

                      tablename property points to 
                      when referenced by: 	
                      uitarget    self        active
Cursor is in:
MasterField       master     master    master
DetailField         master     master    detail  

VERSIONS: All

SUBJECT: Locating in detail table

BY: MARK PAUKER

All links within Paradox's data model are master/detail relationships. A 1-to-1 relationship is more of a peer relationship than a hierarchical one, but unfortunately, that's not the way Paradox works.

My solution to this is pretty simple. Once I get the criteria the user is searching for (field name(s) and value(s)), I attach a tCursor to the detail table, switch to the appropriate index (which will also remove the current range), and do a qLocate. Having done that, I read the values of the link field(s), open a tCursor on the master table, switch its index so I can qLocate on the link field(s) (obviously, I pre-build that index if it doesn't already exist), and do the qLocate. From there it's just a matter of issuing a moveToRecord on the master table.

A few other things to consider: This solution does not deal with the case where the master table already has a range set. You will have to add additional code if you want this to function properly in that case. Also, keep in mind that if the relationship is many-to-1 rather than 1-to-1, there may be multiple master records (pointing to the same detail) as well as multiple detail records that will satisfy the search criteria. This can be somewhat more difficult to track, and may be one of the reasons why Paradox doesn't do it natively.

To index