>>So #1 is the game. With that said, what type of circumstances do you have in mind?
>
>Simple method calls. For example, a textbox has a Validate method (not to be confused with Valid) which performs field validation. At run-time, the field validation rule comes over the wire (via XML) and must bind with the textbox Validate method. The textbox has no knowledge nor does it need to know what came over the wire.

The textbox should have a Validating() event that is raised by RaiseEvent() from the Validate() method.


>However, relying upon return values of simple method calls using BindEvents cannot be used in VFP9.

The issue I've put to you is not can it be used, but should it be used.

The answer is no. BindEvent() with simple method calls is the wrong way to design object systems.

Let's say I'm reviewing some code, and it looks like this:

define class myTextBox as TextBox
   function Valid
      * Make sure we have a value
      if empty(this.value) 
           return 0
      endif

      * A little extra validation before we return
   return this.Validate()

   func Validate
   return
enddefine

If I were a developer reviewing this code, trying to figure out why I was getting the message "This value is invalid" I would look through here, and I wouldn't find my answer. I'd look at the instance of the textbox on the form, to see if it has custom Validate() code, and I wouldn't find my answer.

At this point I'd give up and go looking through the database to see if there are triggers that aren't being satisfied.

On the other hand, if I saw:

define class myTextBox as TextBox
   function Valid
      * Make sure we have a value
      if empty(this.value) 
           return .F.
      endif

      * A little extra validation before we return
      local loValidateOptions
      loValidateOptions = createobject("empty")
      addproperty(loValidateOptions, "lValid", .T.)
      RaiseEvent(this, "Validate", loValidateOptions)

   return loValidateOptions.lValid

   func Validate
   return
enddefine

I would know that delegation was the intention of the developer. I would know that this design uses events because I see RaiseEvent() in the code. Its self documenting. It shows me as a developer that I'm dealing with an object raising events. I don't need to guess.

As systems get larger and more complex, the issue that this presents grows exponentially.

The latter class is better code. You should write your events like this. Always.

There's no excuse for taking implementation shortcuts with your design.

More importantly, what if you had multiple delegates that all returned different values? How in the world would you expect VFP to handle that likely scenario.

It is an untenable design.