John,

Great post. Let me intersperse my replies in your message...

>Hi Doug..
>
>I stopped to make a cup of tea while contemplating a response to your post...

Earl Grey I would hope.. <g>

>
>The lack of macro substitution is oft viewed as the achilles heel of .Net as far as a VFP developer is concerned. .Net does not have macro substitution. This is a fact that I cannot quibble with. Notwithstanding that fact, I will press on..

Indeed it is. As you assert I also do not think that this is a gulf that cannot be bridged.

>
>Macro expansion (ME) has always held a peculiar place. On one hand, folks have wanted Fox to be compiled. On the other hand, folks have come to rely on ME. Of course, the two represent mutually exclusive ideals. As for myself, I rarely use the & operator. In my experience, the most oft scenario macro exp. is used is in the construction of dynamic sql statements. The second most used scenario relates to xbase constructs like Replace, Select, etc... The third most relates to dynamic referencing of objects.

I have found some places where it is useful. Perhaps I have such deeply ingrained habits that I cannot see an alternative <g> but I think that there are legitimate uses of this construct. Absolutely necessary? Who knows..


>
>At this point, I would like to say that if somebody is comitted to using VFP/DBF data, then stay with VFP. It is a blinding flash of the obvious to see and know that nothing works better with VFP data than VFP. This analysis assumes that one is migrating to SQL Server (Which many VFP developers either have done or are in the processing of doing now...)

Agreed..


>
>If you like dynamic SQL statements, stored procedures can build and execute dynamic SQL Statements just as easily as you can in Fox. From a code standpoint, your code is MUCH more readible and cleaner. An over-abundance of macro-expansion begins the slippery slope of unreadible and unmaintainable code. Further because your UI/Middle Tier components have a single interface (the stored procedure), this too lends to cleaner code.

Ahh.. I'm glad to learn that this is possible. I have not had the opportunity to learn this and I'm glad to hear it.

As an aside.. We plan to have SQL or some other 'real' data manager (DB2, Oracle, Sybase, ?? levels) as our ultimate data repository. My suspiscion is that we'll start with Microsoft SQL and if we need one of the others for whatever reason we'll place that behind the SQL data perhaps.. Microsoft may take umbrage at their name being missing from my list but I still have a few nagging reservations on whether or not they can take the kinds of 'hits' that Oracle can and 'keep on ticking', so to speak. My guess is that they will be more than able to handle everything I throw at them but IMO when it comes to stability of O/S's it's hard to beat mainframes and/or Unix. If SQL ran on those platforms I'd then want to add it to my list I suppose... (I guess this screws my chance for MVP some day, eh? <g>)

I quite agree that the usage of macro expansion is overused in many cases and this is simply poor programming discipline or perhaps sheer laziness..

>
>With respect to macro expansion and the traditional xbase constructs, because it is not likely that one will be using VFP/DBF data in .Net, the fact that you are losing this becomes 100% irrelevant.

Right. And, since I can, if needed, use VFP with .NET the issue is IMO doubly irrelevant. I am not attempting to defend macro substitution simply because I like it. Rather, I was asserting the notion that I do indeed think that VFP and VB could very well get so close to each other that they would be indistinguishable -but- that there were these features that could throw the proverbial spanner in the gears. I was wondering what should happen at that point... Your response deals with much of this. The decision to exclude VFP from .NET has indeed set us on a road that could very well mark the sidelining of VFP. *shrug*

>
>As for dynamic object referencing, macro-expansion is really not a good choice for this sort of thing. Yes it works. But, it is a VFP specific feature that can lock you into the Fox-Box. Using object pointers is a much cleaner way to deal with this issue.

Well, in my particular case VFP is really the best choice for our desktop product right now. I don't see anything at this point to challenge this though perhaps Delphi & a good local backend plus driver might be there, particularly since this opens up Linux for me. All I'd need to do at this point is duplicate the Web Connection stuff in Linux to get where I'd like I think.

>
>With all of this in mind, I contend that Macro Expansion and the lack of it in .Net is not a weakness of .Net and is not a bar to the VFP developer wishing to make this migration. At best, it is a perceived limitation. This will be one of the issues I tackle in the coming months.. Somehow, the rest of the world has managed to get by without this singlular Fox Feature...

Agree completely. I also agree that the perception is most likely a perception rather than a reality. I'd appreciate reading your response to this issue.

>
>Do you really believe it is not worth the trouble to go to .Net? You couch things from the perspective of whether you can afford to make the move. I view things from the perspective of whether a VFP developer can afford to not at least plan for the move. Even if one does not feel that he will deliver applications in .Net for 12 months, the time to plan is now. Can you imagine the development talent firms will be looking for in 12 months? I think they will be looking for .Net talent.

Ehh.. I don't have a compelling reason to go there right now. Will I at some point? More than likely. Will I allocate a slice of time to learn. Yes, as soon as I get some time. <g>

>
>This is a rare opportunity. It is a time when we, just like everybody else, can get in on the ground floor. IMO, the next 12 months may be the most critical of a person's career.

I remember the big change that swept through the Fox community when we went to 3.0 and started dealing with the notion of objecs and so forth. Some didn't make the transition for whatever reason. I struggled but that was a rough time personally so I had an excuse. <g> I think you may be right concerning .NET and I, for one, plan on making it a part of my thought process.

What would help me the most would be for a 'foxer' to translate the lingo.