>Hi George,
>
>>As I recall they had a regular column along the lines of "Under the hood" that about the API. One of the areas that I personally think that many VFP programmers are lacking in is and understanding of what goes on "under the hood". Unfortunately, except for sporadic articles, FPA rarely addresses this topic.
>
>Are you talking about API here, or in general "Under the hood" topics? If it's API, I'd like to read/write more about it, but fact is that API development is an out-dated technology. More and more features are only available via COM, not via a procedural API. Advisor must take this into account and print more about COM, not more about API development. In fact, Advisor Answer more and more deals with COM technologies.
>

Christof,

The issue is not one of detailed API coding. Someone on editorial OK'd that FPA published a 'tip' of dubious of dubious quality. In order to check if a floppy was present, they recommended:

RETURN (DISKSPACE(tcDriveLetter)>0)

Yes, there is a peripheral issue that you need an API workaround - the use of SetErrorMode() to allow a critical error to pass through to NT. OK, a cow flew by and it was missed by your (or someone's) technical evaluation of the code. Human mistakes happen.

What is not excusable is that noone in editorial decided to check to see if the 'tip' worked as advertised under 9x, NT and 2K. It didn't. If somone at a lower echelon had reported "this doesn't work right under NT" you'd have spotted it in a heartbeat, and pointed out the error, because you're competent to see and recognize the cause of the problem when it crossed your desk. If you didn't spot it when it (along with 8,147 other random one and two line issues) crossed your desk with no indication there was a problem, that's OK, a human error was made. That noone checked it out to see if it worked, that's a problem.

Addressing this to George rather than me may be the decision made by FPA staff with regard to seeing the issue resolved. That's fine; George made a masterful statement regarding what was wrong and showing how it was done better in the past. Accepting criticism from George, a respected member of the VFP community whose articles you've published in the past may be the way the FPA staff chooses to deal with my individual issues with FPA, after all, I'm a lowly subscriber, where FPA has recognized the value of George's writing in the past by publishing his articles on API-related topics, so the impact of topics raised by him may require more immediate reply.

The API may be outmoded, outdated and obscure, and we'd do the world a favor by getting UT to rip your fine work on STRUCT off the face of the earth, and my own CLSHEAP, which Mr. Frost has pointed out is inadequately documented and poorly coded. I don't think that's a good attitude, but perhaps you're wiser than I in this regard, and all the effort that's gone into exploiting the Win32API should be ripped to shreds to do things in a better fashion. If that's the editorial position of FPA, please have the courage of your convictions to stress the need to retire FPD/FPW code that is no longer a supported product from MS, and that it really ought to be recoded. I see this as a greater threat to the codebase and the stagnation of the community that FPA choosing to print the occasional tip that relies on an API service.

Let's get the horse manure out on the table. Don't dismiss the error as "we shoudln't be using any API code, it's outmoded technology." The API has a place in VFP code, and you know it, I know it, and the API is not the root cause of this issue IAC. Poor editorial review of the tips published through FPA since Steve Sawyer left, as noted by George, is the issue. The quality of the offerings is not up to the standards readers had come to expect of your offerings when Steve was responsible for the tip content. The editors as a whole, and the submission review policy, no one editor in particular, did the FPA readers a disservice with this "tip", and it's my impression that back when Steve did the column, shoddy review of tips was not as visible an issue.

I appreciate your attention to the existance of the problem. I'd ask that you reconsider what the root cause of the problem is, editorial review, rather than the choice to exploit the API. No one editor deserves to by thrashed publicly over this entry being published. Some reexamination of the editorial review of submissions printed as tips needs to be done. The reexamination needs to be done behind closed doors at the next editorial staff meeting; the readers of UT and FPA need not know that the discussion ever took place; we'll note that action has been taken because the quality of the tips offered in FPA will rise dramatically.

I'd be disappointed if the result of this were a blanket indictment of all things exploiting the API were offered up from the staff at Advisor. If as a result, the howling mobs cry out for expulsion of API code backed by the stated editorial positions of FPA and UT caved and removed API offerings from its files, www.esolserv.com, my company's website, will gladly accept the files that the villagers want chased off of UT at FPA's behest and make them available by FTP once we've got our infrastructure in place. We won't be trying to compete with UT, just offering a home for the unloved toys that need and deserve a place to have them made available.

I expect more of you as an individual Christof; I admire the quality of the work you crank out and contribute to the VFP community. I'd hope that FPA could live up to the standards of personal and intellectual excellence you exhibit in the future with their editorial offerings.