>James,
>
>There isn't a difference in instantiation time for a form using objects dropped at design time or doing a set of AddObjects at runtime. AddObjects might be a bit slower because of executing interpretted code to set properties instead of VFP just internally reading the Properies memo. But I doubt the difference is measureable.
>
>It would be nice, but instantiation order is not really an issue for 99.999999% of the VFP forms out there in the world right now. And there are alternatives when the order is important.
>
>Send an email to foxwish@microsoft.com they do pay attention to requests and it doesn't hurt to get your vote counted for a feature like this.

Hello David:

I was not really talking about instantiation time, but more about design. Its easier to just drop a control on a form then set its instantiation order than it is to write (or copy) the code into a method that addobject() the control. I do not agree that firing order is irrelevant to 99+% of the applicactions written -- it seems all of the applications I write have firing order concerns.

This seems to be an area in which we just disagree and it does not seem that either one of us is going to persuade the other.

I will say that while VFP is a good product, it could be a much better product. But, like all consumer products, it is consumer driven. If we, as its users, do not insist on increased functionality, we won't get it because M$ will have no motivation to provide it. Bottom line is that having positive control over firing order does no harm, and in the right circumstances is very necessary functionality.

I have long ago (with VFP3) started communicating with M$ over the lack of firing order control, and intend to keep it up until M$ provides the functionality.

Regards,

JME