I looked at Maurice's article and downloaded his source code. Nice work - but it does not come close to tapping into in the integrated debugging environment ala VB. Nonetheless - there are some intresting techniques employed by Maurice - he is a smart and talented developer. I am not saying you couched it has a replacement. My only point is that as good as Maurice's work is - it does not really address the COM Debugging issue to the degree that MS could - it it chose to...

As for budget being the ONLY reason - I don't think I made that assertion. The only point I was that JK is incorrect in saying that a feature was not cut for budgetary reasons. I agree that there are likely other reasons.

As for the rest of your post - as you always do - you bring up good and intereting insights.

< JVP >

>John I'll challenge the "Budget is the reason". I think it's possibly part of the reason, but, not the main reason. After all, MS is pretty much the most cash rich company in history. If they really wanted too, they could add .0001 percent of their budget to vfp and it would be more than enough to continue to make vfp a bang-up great product.
>As I've said before, COM debugging in it's basic form is done. It would take one read of Maurice's article for the MS programmers to get it and no doubt maybe do a better version or even an equivalent which would still be a major improvement in the base product. Maurice would also probably gladly donate his original work.
>The fact is the given direction to the developent team is, no doubt, to steer clear of anything that will give vfp developers a reason not to go to VS.NET. I really believe the drive is to push both products together at the expense of little or no improvement to vfp in certain areas. I don't think you'll hear an argument against this from Microsoft either. The problem, though, is that we're short-changed in our options to leverage existing vfp code...
>>>Hi John (Koziol, not Peterson!)
>>
>>
>>Cmon - if I can't get a Norwegian to spell my name correctly - there is no hope!! :)
>>
>>
>>>
>>I can not agree with you more regarding your last statement. Although JVP without any doubt is a prominent VFP programmer, most of his arguments here on the UT the last few months can only have the prupose of pushing his own ego. Germans call these people "besserwisser" meaning someone who always knows best.
>>>
>>
>>You probably will not believe this - but it has nothing to do with ego. There are definitely those in this business with healthy egos - and I don't profess to say that I don't have an ego - I do. More than anything - I am opinionated. If I really cared about my ego - I would likely couch what I say and frame it in a way that it would be more acceptable. People with ego issues worry more about their egos getting bruised. That has never been an issue for me.
>>
>>As for JK's comment about things not getting cut for budgetary reasons. He is wrong on two counts. First - in the abstract and Second - on facts specific to VFP. With regard to the abstract - in any project - there is a budget. Given those constraints, you cannot possibly do everything. If a particular feature gets in, it may come at the expense of one or more other features. It is one of the sides of the project management triangle - and this a limiting constraint. With regard to issues specific to VFP - I know for a fact that things like COM Debugging did not make it in because it would not be cost justifiable - that it would have to come at the expense of other features. I know this based on discussions with 3 individuals currently on the team or formally on the team. This is a budgetary reason/constraint in its purest sense.
>>
>>So - regardless of what you may think my motivations are - which should be irrelevant, the fact is that contemplated new VFP features have been cut for budgetary reasons. The correctness of that statement is what is relevant and that is what should be challenged. My ego has nothing to do with that.
>>
>>< JVP >