Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Return values and other standards
Message
 
À
05/11/1998 11:13:53
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Divers
Thread ID:
00154804
Message ID:
00154863
Vues:
18
Yes, I can see the value of putting the error content in a different object. Nice design. Currently, I store the cFirstErrorMsg and cLastErrorMsg as properties of the object, and when I go to reset the object to their default state when they encounter some kind of error--i can do that for all properties except those releated to the error state. Of course, storing an object reference to a collection of cannot be reset either . . . hmmmm, i guess I'll wait to work on this until I really need to worry about stateless objects. (perhaps some type of observer pattern here would work . . .)

So, does how will your UI get a value of an object property?

lcUIValue = oBiz.cPropValue

or

lnRetVal = oBiz.GetPropValue( @lcUiValue )

or ?

Thanks.

>Mark ---
>
>I'm working on a writing up an object scheme that handles this exact problem.
>
>In general, consider adding a collection property to the object you are calling: Alerts(). Have your UI return 0 if success or -1 if failure. If a failure is indicated, you can always query the obj.Alerts() collection to find out what the error(s) are.
>
>Obviously, you also need to be heads up in the how you set Alerts, but a really keen way of doing it is to use the new Assign event for all properties in the object to set Alerts and intercept values that violate data or business rules. BTW, you also need to reset the Alerts collection in the object internally...
>
>
>
>>I recently learned the C programming standard for method return values:
>> 0 if the method completed successfully,
>> >0 the method encountered some application error.
>>
>>I was wondering how people implemented "Get" methods.
>>
>>You can stick to the approach above and return the appropriate property value in a parameter passed by reference, but this is an awkward interface for the UI.
>>
>>If you don't use this approach, then how do you tell the UI an error occured? I suppose you could return either the property value or some special value to indicate an error, but this also creates a "muddy" interface for the UI-- for example, the property value could be a different type than your error return value.
>>
>>Thanks.
>>
>>- Mark
----------
Mark Bucciarelli
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform