RE: UI/BizObj references question

2006-08-10 Thread David Stevenson
Ted, >...While it's true you can use an lSuperUser_Access method to extend this, why hide the possibility that code fires when you can code a method in the first place? My usual approach is to work through methods instead of properties as much as possible. This is perhaps due to working quite oft

Re: UI/BizObj references question

2006-08-10 Thread Michael Babcock
Ted Roche wrote: On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote: Aah, but in my scenario, the UI's Init event sets a property ONCE based upon the BizObj's function result, and hence, the scenario you give would still mean no changes to the UI. Hence why I feel that that served the

Re: UI/BizObj references question

2006-08-10 Thread Ted Roche
On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote: Aah, but in my scenario, the UI's Init event sets a property ONCE based upon the BizObj's function result, and hence, the scenario you give would still mean no changes to the UI. Hence why I feel that that served the interface idea ins

Re: UI/BizObj references question

2006-08-10 Thread Ed Leafe
On Aug 10, 2006, at 4:15 AM, Andy Davies wrote: "Code to interface not to implementation" also implies that it's better to ask the object's method than to query the object's properties. If you consider a 'property' to be a wrapper round a set/get method isn't this a distinction without a dif

Re: UI/BizObj references question

2006-08-10 Thread Andy Davies
> "Code to interface not to implementation" also implies that it's > better to ask the object's method than to query the object's > properties. > If you consider a 'property' to be a wrapper round a set/get method isn't this a distinction without a difference? - and the fact that this sort of ques

Re: UI/BizObj references question

2006-08-09 Thread MB Software Solutions
Ted Roche wrote: On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote: I had originally thought of something simple like "this.enabled = thisform.oBizObj.IsSuperUser(tcUserID)" but I didn't like the idea of a function being called across object lines several times (repetitively, as Refr

Re: UI/BizObj references question

2006-08-09 Thread Ted Roche
On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote: I had originally thought of something simple like "this.enabled = thisform.oBizObj.IsSuperUser(tcUserID)" but I didn't like the idea of a function being called across object lines several times (repetitively, as Refresh events would hav

Re: UI/BizObj references question

2006-08-09 Thread MB Software Solutions
Ted Roche wrote: On 8/9/06, Michael Babcock <[EMAIL PROTECTED]> wrote: Would you have your UI button's refresh event refer to the business object's property, or gather that property from the BO into the UI's property set and refer to that instead? For example, which would you choose for cmdS

Re: UI/BizObj references question

2006-08-09 Thread Ted Roche
On 8/9/06, Michael Babcock <[EMAIL PROTECTED]> wrote: Would you have your UI button's refresh event refer to the business object's property, or gather that property from the BO into the UI's property set and refer to that instead? For example, which would you choose for cmdShowPayRates.Click:

RE: UI/BizObj references question

2006-08-09 Thread John Gunvaldson
this.enabled = thisform.oBizobj.lSuperUser ...or... this.enabled = thisform.lSuperUser (whereby lSuperUser property was retrieving and set from call to BO) My opinion would be this is a case where there is a published interface to the oBizobj that returns the status of this user - and

UI/BizObj references question

2006-08-09 Thread Michael Babcock
In the UI, certain controls behave depending upon settings from the bizobj. For example, a certain button might be enabled for a SuperUser, but not for a different type of user. The business object has a property named lSuperUser and reflects whether or not this guy should have access to the