Hi Ed,

>Now if you use CLASS properties and methods, which
>is the right thing to do, you have to This.Parent.Parent.Parent.Parent.Parent
>to get to them, since you can't use ThisForm because your coding in class.

I see. OK, what options do we have in the language? We can use #DEFINEs:

#DEFINE ThisClass This.Parent
#DEFINE ThisClass2 This.Parent.Parent

and so on... of course you have to know the class hierachy level. If speed is the problem because multiple references have to be resolved, you can use WITH...ENDWITH when you access more than one class property.

THISCLASS would make this certainly easier, but what are the drawbacks and is it really faster? THISFORM and THISFORMSET can easily be resolved, because they are the outermost container and VFP handles forms differently than any other class anyhow. But THISCLASS would VFP still force to evaluate the hierarchy. After all, as soon as you add this container to another form or class, THISCLASS for new code would refer to the outer container, but THISCLASS inside the class must still access the inner container. IOW, even when traversing the class hierarchy (eg because of DODEFAULT()) on every level THISCLASS might refer to some other object. All existing references OTOH remain static at least in the class hierarchy.

In other words, the risk to implement this feature is probably high as it differs from any other reference shortcuts we have now. And if I were in charge to decide about this feature, I would probably request more reasons to convince me why this is an extension that it's worth implementing it.

>2) I like the structure class workaround, but for true API interfaces, I
>need callback capability and addressof like VB or C.

There are some solutions available for this, but I can't say how reliable they are. One is to use a VB ActiveX control that provides the Callback function and then raises an event where you can place VFP code. Another involves the VFP API function _Execute() called from within the callback function that resides in a FLL.

>>Even the clunky way we have to just get Hwnd, why not make it a property of the form?

In APIX.PRG of my struct class you find a function to do this. And since it's not that difficult, I'd rather like to see some bugs fixed, then a HWND property added to the form. In VFP you can do something you can't do in VB: You can add the HWND property to your base form class.

>>There was another suggestion of providing controls that are true windows subclasses, with the Hwnd and everything available.

What about subclassing the Form 2.0 ActiveX controls to add data handling behavior?

>>These controls could exist in addition to the standard bitmapped controls for backward compatibility. To help phase out the bitmapping of forms without breaking backward compatibility.

Actually I don't see that much advantages on native Windows controls. *s* Even Microsoft doesn't really use them, because a) many simple controls have been superseeded by far more complex controls. For example a listbox is often replaced by a treeview, plain buttons have been replaced by "cool" buttons which are not windows anymore. And even the menus have changed.

>This item has really bitten alot of people. See the thread from hell 'Rushmore Design Flaw - HEADS UP!' for the complete skinny. I do agree that SQL server and views are the way to go, but there will still be a large free table developer base in our lifetime. So don't write it off just yet ;)

Yeah, but why should the VFP team add just another feature and change the behavior how certain things work, just because many developer forget to add NOFILTER to the SELECT statement. After all, this behavior really goes back to FP 2.5 and probably even further back.

Christof