Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Why Register?
Message
From
03/02/2000 13:37:53
 
 
To
03/02/2000 12:40:38
Michael Dougherty
Progressive Business Publications
Malvern, Pennsylvania, United States
General information
Forum:
Visual FoxPro
Category:
ActiveX controls in VFP
Title:
Miscellaneous
Thread ID:
00326222
Message ID:
00326817
Views:
29
>Geez Ed, thems fightin' words. ("woefully ignorant" etc.)
>

No, it's accurate. The details of the hows and whys for the registry have been spelled out in many documetns since the initial release of WinNT. The issue of the Windows registry is notr a VFP thing at all, but a Win32 thing. While there are inadequacies in the VFP docs, it's not the responsibility of the product documentation to detail out the inner workings of the OS, only to provide guidelines on how to do it in the context of the product. If this were not the case, then MS would have to include about half of the publications now offered through MS Press to adequately document Win32 internals as might be applicable to VFP. Certainly, at a minimum, all the Platform SDK docs, all the books ever written on OLE/COM internals, Richter's "Advanced Windows", all the Resource Kits, etc. And guarenteed that the vast majority of the people, faced with this daunting stack of reading, would bitch about the docs giving them hernias!

>If you understand the mundane details about versions and dependancies, the wizards are a great time-saver. The problem with not understanding the wizards is that what they do is essentially magic. I doubt any programmer who spends hours writing their app wants to trust the installation to wizardly magic. In the re-use and recycle "Rapid Application Development" world, the first cut is usually the documentation. (few developers write really useful docs anyway, because they're too intimate with the details for someone who's never seen the app) This can lead to some frustration when the wizard doesn't do the job exactly like the developer hoped, and there's no resource to figure out what needs to be done to fix it. (and who believes that wizards are infallable?)
>

The VB crowd is even more dependent on these technologies, and if you've read the VB docs, they're no more detailed and descriptive. Virtually ever VB app has ActiveX stuff in it, since that's how you put controls on forms in VB generally. I certainly do not belive that the wizards are infallible, and it's the developer's responsibility to know enough about the tools they work with -by choice - to deal with them. It is entirely possible to not use any ActiveX controls in development; if you don't use any of them, the VFP Setup Wizard does a more than credible job of installing the runtime components for VFP on target systems on a cross-platform basis.

God help anyone who feels the registry is a problem if they ever write a VB app, or a J++ app, or a Delphi app, or a VC++ app, that uses any third party ActiveX, or anything with ODBC, or anything much beyond "Hello World" as a console app.

I can sympathize with ignorance, and generally try to help as I can to correct that. Luddite stupidity is uncorrectable, and IMO, unforgiveable. Wailing that the Windows registry is evil and unnecessarily complicates the issues of deployment and operations show not only a lack of understanding of the Win32 environment, but of the requirements of application development and deployment in any of the competing platforms. Like I said, Win32 is a pussycat compared to Unix. It's not an issue of VFP, it's an issue with the theory and operation of the platform. As pointed out, noone is pointing a gun at the man forcing him to use VFP, and he can work with clients using platforms other than Win32 if he feels that these alternate platforms are a better option for the client's applications.

He has three choices in my book, learn how to deal with the registry and Win32, go to another platform, or stand there and howl at the moon and suffer the comments of people who tell him what his options are and try to point up that the alternatives are worse. If he wants to avoid Win32, there's always DOS. Or Mac. Or Linux. And he can successfully avoid the evils of VFP on all of those - he has to in fact.

>I think if you step back and looked at a bigger picture, you'd agree that the reason for the numerous 'helpful' programs you mentioned is because the process is actually complicated and time-consuming. (nothing related to computers has ever been the way old-school management thinks of them- "You just push a button, and 'it' does all the work", at the same time they're afraid to learn how to push the button)

OK, we agree, being a Luddite is a bad thing. People offer tools to make life easier. VFP is a tool for developing data-centric applications. Using the tool requires that you work in the Win32 environment, with all that entails. That includes the need for tools to deploy applications, and the selection of deployment tools is on a par with selecting VFP in the first place. Irt's muchtoo late in the development process to say "OK, I'm ready to put this in place...what the < expletive deleted > do I need to put out on target systems? How do I handle this? Why's everybody always picking on me???

Michael, not figuring out how to deploy is as silly as going to hang a picture in the living room without having a clue about how to make it stay up where you want it. If you plan ahead and have a picture hook and a hammer, and there's a stud in the wall to drive it into, this is a good solution. If you have a 100lb picture, use a picture hook and drive it into the wallboard, what's going to happen to the picture when you hang it?

DOH!!! -- H. Simpson
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform