>Take a Winform, for example. Drop a command button on it. Double click it to bring up the code window (which, BTW, very nicely builds the code for you). You see something like ... Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs)
>More than anything else, the design simply looks like you're breaking a whole bunch of encapsulation rules.

If you're used to something else, you're right, it "looks" that way. But really, you aren't breaking anything.

In VFP, when you're adding code to a command button like that, what it's really doing is creating a subclass of the command button and adding specific code to the Click event. And we both know that those events should be calling methods on the form eventually anyways. By this process you are saying (in VFP) to the command button:

"sit there and wait for someone to click you, when clicked you have to know what to do"

Where as with .NET it's really like saying:

"sit there and wait for someone to click you, I'll take care of the rest"

So with VFP, it also looks like you are breaking encapsulation, and you really are! With .NET, delegation only means that the system is more encapsulated (as the command button is only interested in allowing the user to provide input and notifiying the form when that occurs).