>
>If you mean a design bug or bad design, I'd doubt it. You must recall that objects such as text boxes, command buttons etc. are different in Visual FoxPro than they are in C/C++. In other words, they're not windows with their own Windproc to handle Window's messages. All of this, including an individual form's (which is a window with a Windproc) messages are routed to the main window who's Windproc handles every thing from there. This is why you can't, without resorting to an ActiveX control, access API calls requiring a callback.
>
>This means that special considerations have to have been made by the Fox Team. Prior to 8.0, you could neither sink nor raise and event. Perhaps this behavior will change, but it looks like considerable thought was given to the design given the extent of the documentation on it.
>
>
>I only say that BINDEVENT it is optimal with Users Methods,
> but with Native Properties o Events it is a true chaos.
>
>Example for Events:
>

>Form.Resize       yes
>Grid.Resize       no
>Container.Resize  no
>...
>Form.Active        yes
>Page.Active        no
>...
>...
>

>
>For Properties the situation is worse.
>
>A little Table "Native BINDEVENT support" on VFP Documentation
>it demands job too much ?
>
Fabio,

Don't you see the pattern? A form is a window and gets passed messages. The other objects aren't and don't.