Alex,

>Is it OOPily correct to say:
>
>messagebox("And the primary key is... " + str( v_providers.iid))
>
>Or is there a way in which we can do it by asking the business object to give us the value?>

There are two main cross-tier traps I see developers fall into:

1) Placing Tier 2 business logic in the Tier 1 user interface
2) Placing Tier 1 user interface logic in the Tier 2 business objects

Here are some tips for avoiding these problems:

*** Create business objects first! ***
One of the best ways to ensure that you separate tier 2 (business logic) from tier 1 (UI) is to create your business objects, then instantiate and test them from the Command Window outside the context of the user interface. This helps ensure that your application logic resides in the business object rather than the UI.

Only put user-interface specific code in the user interface!

*** Check your business objects for UI dependencies ***
Your "pure" business object classes should not interact with the user interface, including displaying messages to the user. This means you shouldn't find calls to MESSAGEBOX, MsgSvc or This.Parent within your business objects.

In the scenario you described, if you want the business object to return the primary key of a newly saved record you could add a new "iUniqueID" property to your business object, then place code like the following in your business object's Save() method:

LPARAMETERS tlAllRows, tlForce
LOCAL lnRetVal, lcAlias

lnRetVal = DODEFAULT(tlAllRows, tlForce)
IF lnRetVal == FILE_OK
lcAlias = This.GetAlias()
This.cUniqueID = EVAL(lcAlias + '.' + This.cUniqueIDField)
ENDIF
RETURN lnRetVal

(Remember to specify appincl.h as your business object class include file when using Framework constants such as FILE_OK.)

Afterwards, your UI can retrieve the unique ID value from the business object's iUniqueID property, or, better yet, make the iUniqueID property private, and create a method that returns the value which can then be displayed.

Regards,