====================================== FoxPro Developers Network of San Diego ====================================== FoxDev TipsLetter #98-2 DECEMBER 15, 1998 Website: ---------------------------------------------------------------------- CONTENTS: * Calendar * Drew Speedie does MaxFrame * Technical: * Installing VFP 6.0 Dan Covill * De-wizzing Forms Dan Covill * Button Bars on Forms Dan Covill * Making Help Files * Other Stuff: * MSDN Website Features VFP * Microsoft:Ford::Linux:GM? Monty * Administrivia ====================================================================== CALENDAR: January 6 Steve Settimi (Project hooks) Regular location, 6 PM ** Heads up! It appears that our location will be changing again, but not til after the January meeting. We'll keep you posted. ====================================================================== DREW SPEEDIE DOES MAXFRAME by Dan Covill Drew Speedie, of FoxPro Advisor fame, spoke at a special meeting of FPDN at TISCOR in Poway on December 2, presenting a demo of the latest version of his Visual MaxFrame Professional. As is apparently his custom, Drew dispensed with any introductions and plunged directly into a demonstration, creating a new "UG" application (meaning User Group, not UGly) and explaining how it worked. It was pretty impressive; mutterings of "cool" were heard from time to time. (I'm not sure whether "Speedie" is his real name or a description of his presentation style!) To this observer, the biggest strength of VMP is the wealth of working experience that's built into it. For example, he set an option so that ALL the files were created with the prefix 'UG'. But you can change any individual file if you need to. Configuration files that let you test without logging in each time. User login that keeps records you can look at later. Library/class documentation (a revolutionary concept in the Microsoft world) where you can find it at design time. Drew points out that all frameworks, including his, tend to institutionalize the creator's way of doing things. He's clearly a programmer - his way involves lots of "modi comm"s from the command window and less clicking and dragging than Microsoft practice. I'm a programmer, and I think that's good. If you're a member of the GUI religion, you might feel it isn't automatic enough. Drew says that VMP is a framework, not an application generator. He doesn't like Wizards (not even Gandalf?), so while VMP includes several base data entry forms, it won't build them for you. You're presumed to know what you want to do. For me that's a plus. VMP costs $350; a public domain (abbreviated) version is available for free download. They are now selling version 4.0, even though it isn't completely done yet (updates and documentation being added regularly). Drew says if you're starting a new project, you'd be better off starting in 4.0 than building it with 3.0 and trying to upgrade. The website is at . ====================================================================== INSTALLING VFP 6.0 Dan Covill If you haven't installed VFP 6.0 yet, here's a tip. Whatever you do, do NOT accept the default installation directory. It is: C:\Program Files\Microsoft Visual Studio\VFP98 If you use the default, you'll curse your decision every time you have to include VFP in the path, or try to CD to it, or try to navigate to it in Explorer. In addition, things that display the path will choke on it and either display the leftmost 30 or so characters (not helpful), or just the front and back with a big chunk missing out of the middle. And there's frequently no way to find out what that middle was! If you have, like many of us, separate partitions for Windows and for your own work, I suggest a root-level directory on your work drive, because you'll probably end up adding things to VFP (like SuperClass) it would be nice to have backed up. Mine is D:\VFP60, and I have one right beside it called D:\VFPLIB for all my library routines and my experimental areas where I try to find out what the #%*&! VFP is doing! I did use the default directory for the MSDN documentation/help. You never have to access it directly so there's no problem. I originally installed VFP 6 in the default directory on my home machine, then moved it! I patched up the Registry entries I could find, and fixed the shortcuts, and it worked just fine, EXCEPT.... it couldn't find the Help file! Help from the Start menu worked fine, but not from VFP. I ended up re-installing, which somehow fixed it. Go figure. ---------------------------------------------------------------------- DE_WIZZING SCREENS Dan Covill In a moment of weakness, I used the Wizard to build a screen for me. After I moved the fields around a little, I ended up with a fairly nice looking screen that actually worked, EXCEPT... (Funny how that EXCEPT keeps creeping in there!) Except that I now have three new class libraries - WizBase, WizStnd, and WizBtns. I don't want to roll up the whole damned VFP release in every client app I build, but how do I get rid of these things? I found a way. I wrote a little program to go through the .SCX file, replacing references to the Wizard classes and libraries with references to my own, figuring that I'd look at the damage and see what else I had to do. Surprise! It worked the first time! And the second, and the third... In the wizard, I asked for the "Standard" style, so my fields were of class "standardlabel", "standardfield", and "standardform". Any time I find that Class is one of these, I substitute my own class and stuff my class library name into the ClassLoc field. Piece of cake. WIZFIX.prg is only 58 lines, and it's saved my life. If you'd like a copy, e-mail me and I'll send it to you as an attachment. ---------------------------------------------------------------------- BUTTON BARS ON FORMS by Dan Covill If you use the VFP Wizard to build a form, it has these (kind of) neat buttons at the bottom. Like everything else in VFP, they could be very useful EXCEPT. Except that (a) there are too many of them, (b) some are not appropriate, and (c) they reference a bunch of libraries in the VFP\Wizards subdirectory, which you will end up carrying around in all your apps for the rest of your life if you actually use them. BUTTONS IN GENERAL: If you don't like or use action buttons at the bottom of your forms, stop reading now. I do, and I've been doing it for at least 10 years, since FoxPro 1.0 let us define windows and put "prompts" at the bottom. These "prompts" have evolved into what I call either a "toolbar" (ambiguous) or a "button bar". My 2.6 DOS version doesn't actually have separate buttons; it's a string of commands with the hot keys highlighted. In VFP I can turn those into buttons. Turns out the Wizard has already done it. The buttons are the TxtBtns class, and live in WizBtns.vcx. They are: ------------------------------------------------------ |Top|Prev|Next|Bottom|Add|Edit|Delete|Find|Print|Exit| ------------------------------------------------------ All your fields are disabled until you click Edit (or press 'E' - the buttons all have hot keys). Then (a) your fields are enabled and (b) the Add key becomes Save and the Edit key becomes Revert. Neat! The interesting thing is that the code to implement all of this is IN THE TXTBTNS CLASS! Adding records, buffering, dbc's versus free tables, they deal with all of it. That's really useful, although somewhat dangerous (what will you do if it breaks?). I decided the benefits outweigh the risks. THINNING THEM OUT: I make two types of screens - browse screens and view/edit screens. From a view screen the only navigation I do is to let the user look at the next or previous record. So I don't want Top, Bottom, or Find - they'll do that from the browse. I may want the Print button once in a while, for an invoice or something, but I sure don't want it to bring up a list of Report Forms (the built-in behavior). Conversely, from a browse I want Top, Bottom, and Find, but I don't need Prev and Next. And from a browse, my Edit button just brings up the view/edit screen. What I want is TWO sets of buttons, tailored for my two kinds of screens, and WITHOUT ANY WIZARD LIBRARIES. How to do that? FREE AT LAST: Turns out it was easy. The TxtBtns class lives in WizBtns.vcx, but it doesn't inherit from anything but the VFP base classes. So I just copied it into my own class library and voila!, freedom. I copied it again (maybe I should have sub-classed it) to make a ViewBtns class, from which I deleted the buttons I didn't want and removed the code from the Print button. The Print button's click event now just calls thisform.PrintCmd(). The form will either have something in there or make the button invisible. Had to do a little tuning in the navigation methods to allow for the missing buttons, and remove some unused code in init() that was looking for Wizards, but it works fine and it DOESN'T DEPEND ON ANY EXTERNAL LIBRARIES. I've worked on the appearance a little, and am now working on my BrowseBtns class. Now when I de-wizz a wizard-built form, I just deep-six the TxtBtns from the bottom and plug in my ViewBtns. If you'd like a copy, just e-mail me. ---------------------------------------------------------------------- Making Help Files Last issue I asked for experiences in generating VFP Help files. Duke Lotherington was kind enough to send me the following: When we produce our mediocre documentation and/or "help" content, we use HTML with Frontpage as the authoring tool. Reasons: (1) I've never liked "Windows" help, (2) HTML seems like the thing to do these days, (3) the same document can serve as user documentation and context help, and (4) posting to our web site means the documentation is visible to the client and our staff and it doesn't get lost on the back shelf as easily. It is not difficult to shell to the browser and go to a link in the HTML document via an F1 keypress or button click event in VFP. "Duke Lotherington" Is Duke the only one doing Help? ====================================================================== VFP ARTICLES ON MSDN WEBSITE (From the Rocky Mountain Fox User Group) As of press time, the Microsoft Developer Network home page at features the VFP6.0 logo with the headline "MSDN delivers more goods on Visual FoxPro 6.0. A link sends you to which lists the following: 1. An interview with John Rivard, lead developer for VFP 6.0. 2. An introduction to VFP for developers not familiar with the product, by John Swenson. 3. "Customizing Visual FoxPro 6.0 Application Framework Components", by Lisa Slater Nicholls. 4. "Microsoft Transaction Server for Visual FoxPro Developers", by Randy Brown. 5. "The Visual FoxPro 6.0 Class Browser", by Steven Black, details changes to the Class Browser in version 6.0. 6. "Using the Euro Symbol in Visual FoxPro", by McAlister Merchant. 7. "Visual FoxPro Coverage Profiler Add-Ins and Subclasses", by Lisa Slater Nicholls. [Editor's Notes] You may have to register with MSDN on-line, which involves a fairly tedious multi-tier questionnaire (you do remember your mother's high-school grade point average, don't you?), but turns out to be well worthwhile in the end. The John Swenson article is full of useful quotes by Robert Green. Examples: "That's because Microsoft designs Access for Office users. It's a desktop application, while Visual FoxPro 6.0 is a programming language and developer tool." "FoxPro developers are very much driven by their customers, probably more so than any other developers." If you ever get involved in "why FoxPro?" discussions (who doesn't?), you need these documents. [DC] ---------------------------------------------------------------------- Microsoft:Ford::Linux:GM? by Monty The following is an e-mail letter from "monty@sprintmail.com" that was sent to Jerry Pournelle's always interesting Chaos Manor website . (You may remember his column in Byte.) To: Jerry Pournelle From: monty@sprintmail.com Subject: Second computer revolution -- Microsoft:Ford::Linux:GM? Your essay on the Second Computer Revolution reminded me of the history of the automobile industry. Before Henry Ford, there was a flock of tiny automobile companies, none of which dominated the industry -- to the extent the production of automobiles deserved the name "industry" at all. Automobiles were curiosities, priced out of reach of all but the wealthiest. Henry Ford applied industrial engineering methods relentlessly, to drive costs down. He created the mass-production automobile industry, then dominated it for years. His style of management was centralizing and dictatorial -- not only did he not cultivate subordinates who could think and act independently, he systematically drove them away. He never asked his customers what they wanted -- he knew what they wanted, and by God that's what he was going to produce, and people would by God buy it when he produced it. And he was right -- for a while. For a long while. But then Alfred P. Sloan took charge of General Motors -- a hodge-podge of mutually antagonistic formerly-independent auto manufacturers put together by his predecessors. Sloan invented the decentralized industrial corporation. (A student of American political history might be tempted to say that Sloan merely applied the original Federalist principles to industrial management.) And he invented (or maybe discovered?) the segmented automobile market and invented (no question here) the used-car market. And GM left Ford gasping in the dust. And Henry Ford not only never understood what he had done wrong, he never even grasped that he had done anything wrong. The Ford Motor Company only survived because he died before he could quite completely destroy it. Would Sloan have been able to make his contribution, had Ford not previously made his? No. But that doesn't somehow transform Sloan's contribution into a mere derivative of Ford's. But I've been wondering who will play Alfred P. Sloan to Bill Gates' Henry Ford. And if I had to guess, right this minute, I'd have to say: Linus Torvalds. --------------------------Administrivia------------------------------- This newsletter is a service to members of the FoxPro Developers Network of San Diego (FPDN). The editor (Dan Covill) is solely responsible for the content, Barbara Peisch does the distribution. E-mail the editor YOUR tips, comments, complaints, and rebuttals. Editor: Dan Covill 619-492-9552 Board of Directors: Eric Lendvai - President 760-439-6617 Art Bergquist - Vice Pres 619-451-3710 Claude Nikula - Secretary 619-615-6318 Barbara Peisch - Treasurer 760-729-9607 Randy Barber - Director 619-670-7542 Steve Settimi - Director 619-262-5883 ----------------------------------------------------------------------