====================================== FoxPro Developers Network of San Diego ====================================== FoxDev TipsLetter #99-1 JANUARY 20, 1999 Website: Editor: ---------------------------------------------------------------------- CONTENTS: * Calendar * Steve Settimi Hooks a Project * Tech Tips: VFP 6.0 Updates Available Rocky Mountain Legacy Printing in VFP Dan Covill * Other Stuff: We Exist! We Exist! Dan Covill Nothing Runs Like the Fox Todd Landrum Some VFP Timing Results Dan Covill * Administrivia ====================================================================== CALENDAR: February 3 Steve Settimi "FPW to VFP in 3 Giant Steps" Regular location, 6 PM Steve's topic will be moving from FPW2.x to VFP5/6 while creating the 3-Tiered approach (UI, Middle, Backend). He will show: a. how to tweak the Convert Wizard to map to your own class Library b. how to create a Business Rule Class with the thinnest possible client. c. how to link the middle-tier RuleObject to the first-tier Business object. March 3 "The FoxSolutions Application Framework" by Bill Heitstuman at Solutions Consulting Group 6540 Lusk Blvd. (time & directions will appear later) ====================================================================== STEVE SETTIMI HOOKS A PROJECT by Dan Covill At our January 6 meeting board member Steve Settimi demonstrated the use of Project Hooks, a new feature in 6.0. Steve pointed out that "project hooks" are more properly called Project Manager Hooks, and are referred to as such in the documentation - you won't find any entry for "project hook". It's in Chapter 32 of the Programmer's Guide in the MSDN files. The ProjectHook class has a set of properties that give you all the information you could get by reading the .PJX file; in addition you get the events and methods associated with the Project Manager's command buttons. You can initiate, monitor, or trap any of the Project Manager actions as required. Steve showed a form using a project (manager) hook to list the components of a project and the type of each. When he needs to work on a component, he uses the project hook to tell him the component's home directory so he can CD there. ====================================================================== VFP 6.0 UPDATES AVAILABLE from the Rocky Mountain Fox User Group Three updates for Visual FoxPro 6.0 are now available for free download on the VFP web site . You may be required to enter your VFP 6.0 product Id number (which can be found by selecting Help / About Microsoft Visual Foxpro from the VFP system menu). The first update (252k) is for the VFP Setup Wizard, which is used to create distribution files. A readme file describes the 'Known Issues Addressed' (MicrosoftSpeak for "Bugs Fixed"). The most significant fixes are in the ares of distributing multiple ActiveX controls with your app, and distributing 2 files with the same name but in different directories. The second update (441k) is for the Component gallery and Foundation Classes. It fixes 24 problems in the Component gallery, 18 in the Class Browser, and 14 in the Foundation Classes. Last is a VFP 6.0 ActiveX Control Updater (115k). Several of the commonly used ActiveX controls included in VFP such as TreeView and ListView were part of ComCtl32.ocx. Starting with version 6.0, these same controls are instead stored in MSComCtl.ocx. Forms created in VFP 5.0 will use the old versions in ComCtl32.ocx, even when run in 6.0, since the .ocx name is stored in the form. The ActiveX Control Updater includes a program MSConCtl.prg to fix this. While the 5.0 form is open in the Form Designer, you can run MSComCtl.prg to update references in this form to point to the new versions of these ActiveX controls. ---------------------------------------------------------------------- LEGACY PRINTING IN VFP by Dan Covill In general, FoxPro 2.6 legacy applications run fine under VFP. Ok, the windows look ugly, and there a few small exceptions, but they run. Watch out - you're in for a nasty surprise when the printing begins. Output from the Report Writer is probably Ok (I wouldn't know - I never use it and haven't checked), but anything generated by the good old "set print on" or "set device to" commands is waiting to bite you. The VFP syntax is the same as for 2.6, with a few extensions, but the resulting output is radically different, as your users will point out to you when they get their first printout. Here are some of the problems and what I've come up with to deal with them. (The following assumes a Laser Printer. I don't know what you get on a dot matrix, but it's probably ugly.) Default Font: VFP prints using 10-point Arial by default. If you just print something in VFP, using the good old '?' command, the output is in Arial instead of Courier, and all your character spacing is junk. (If you use the at construct, then you'll still have columns, but the position is calculated at .06" per column, or 16.66 chars/inch. And numeric columns align on the left digit.) A partial cure is the "SET PRINTER FONT" command SET PRINTER FONT "Courier", 12 where 12 is the point size (12-point Courier is 10 chars/inch). EXCEPT... a. Printing starts 2 lines higher on the page. Why?? b. You can't use the 80th character position. If you do, that character wraps onto an additional line! Setting _ASCIICOLS or _RMARGIN to 81 doesn't help. c. You'll get an extra blank page, free of charge, at the end. d. Every time you issue a "set printer to", it goes back to Arial 10. e. Who knows what the available font names are? VFP Eats Escape Codes: When you "SET PRINTER ON", VFP considers any LaserJet Escape sequence an affront to its sovereignty, strips off the Escape character, and prints the rest of the code sequence in the middle of your output. Lovely. Before the Redmond Tabernacle Choir jumps up to sing three choruses of "Use The Report Writer", let me point out that those of us with clients often have to deal with specific things the client wants. This has in the past involved using PCL code sequences for things like boxes, shading, barcodes, special font cartridges, etc. This was easy and worked fine in FoxPro 2.6, although it sometimes required use of the '???' (direct to printer) command. Anyway, we're talking about running existing code, and those PCL codes are already there. So don't tell me about the Report Writer. The Good News: None of the above happens if you "set printer to" a disk file! Apparently, the print dragon thinks you must be doing some stupid mail-merge stuff, doesn't bother to help screw up your page and font, and lets your PCL code sequences pass unchallenged. But there are still two problems. '???' Doesn't work in VFP The '???' command is still legal in VFP, but totally screws up your page. When a '???' is executed, everything printed before that disappears. If you change the '???' to just '??', then you run into some of the problems that '???' fixed in the first place. In particular, long control sequences run afoul of FoxPro's character counting and end up with extra line feeds being inserted out of FoxPro's impulsive generosity. (Yes, FoxPro 2.6 did that too, which is why we used the '???'.) Note: The on-line "Help" still has the same documentation for '???' that it had in 2.6. But '???' hasn't worked since VFP 3.0, as is well documented in the "Hacker's Guide". How do you Print the Disk File? Once you've put what you want into a disk file, including your control codes, then "copy file to PRN" works just fine, and everything prints the way you wanted it. EXCEPT... EXCEPT... The "PRN" appears to be complete unaffected by anything you do to printer selection in Windows. This includes selecting different printers, changing from portrait to landscape, and specifying the number of copies. So if what PRN does is what you want, you're Ok; if not you're out of luck. (If somebody knows a way around this let me know, quick!) Dr. Covill's Snake Oil Cure: Adding all this up, I consider the following to be the only reasonable way to make legacy printing work under VFP: 1. Always, ALWAYS, print to a temporary disk file. This avoids the Arial dragon and his annoying henchmen. You can use good old sys(3) to get a file name. 2. Remove all instances of '???' and replace them with '??'. This may bring back some old problems; if it does you'll just have to deal with them. 3. When your output is complete, copy the disk file to the printer, using "COPY FILE TO PRN". Gripe: Why does Microsoft, after making so many difficult jobs easy, have to punish us by making easy jobs difficult? I suspect the reason things work the way they do is that VFP was built from FoxPro 2.6 for Windows, and thus inherits much of the awkwardness of that product. Kind of like using your half-witted cousin for a sperm donor... And why doesn't ANY of this appear ANYWHERE in my 250 Mb of "Help"? ====================================================================== WE EXIST! WE EXIST! by Dan Covill The lastest issue of the MSDN "Flash" (e-mail newsletter) contains a URL to the most fascinating reference I've seen in years. gets you to the Microsoft Internet Developer magazine site (it used to be Microsoft Interactive Developer), and guess what? The February issue has VFP 6.0 on the cover! The main article starts like this: "If you've found that Microsoft Access doesn't meet your needs, but you aren't ready to leap to SQL Server yet, there is a middle ground. Visual FoxPro 6.0 is a Webriffic database package that hasn't gotten the attention it deserves." I was amused by a reference to VFP 6.0 as the "Rodney Dangerfield of Microsoft Visual Studio." The article is very positive, but ends by pointing out that "not being able to share components with other tools hurts Visual FoxPro when it's time to choose tools for building components." ---------------------------------------------------------------------- Nothing Runs Like the Fox By Todd Landrum (Rocky Mountain Fox User Group, September 1998) Recently I was called on to take a look at re-writing a corporation application. The application dealt with users and demographic information about them. They were planning to use it for about 10,000 users (a small subset of the total users) with about 300,000 demographic responses. Their first attempt at writing the app had been in Paradox. They realized they might be in trouble when loading the Paradox tables from the mainframe text files was taking 24+ hours. The main part of the application consisted of finding users who have demographic answers A and B (it was a little more complicated than that but you get the idea). This processing was taking about 3.5 minutes in Paradox. The application had to do this processing over and over. Waiting 3.5 minutes was not going to be a very user-friendly application. This is where I entered the picture. I assured them that FoxPro could do it much faster and we could easily just run some tests to see just how much faster. Their paraphrased answer was "FoxPro? Isn't that dead? Besides, we'd really like to do it in Access. We hear that it's really cool." I shook my head, calmly explained that FoxPro wasn't dead, explained that Fox is faster than Access, all to no avail. They wanted to try it out in Access. So I took the Paradox files back to my office. I attached to them in Access and ran some queries to turn them into Access tables (something Access does very well). I ran a couple test queries and lo and behold Access reduced the 3.5 minute processing down to 29 seconds. That was quite an improvement and the client was ready to do it in Access but I knew Fox could do better. I convinced them we should test it in Fox. I converted the Access tables over to Fox tables and ran some sample queries to test it out. Fox could do it in 4 seconds! The client was duly impressed and we did the project in VFP. This would be a happy ending in itself but it doesn't stop there. The client got the crazy idea (as they are apt to do) that, if Fox is so fast, why don't we throw some more data at it? Something along the lines of 200,000 users and 7 million or so demographic answers. Frankly I think they were growing tired of my snide remarks about FoxPro's abilities and wanted to bring Fox to it's knees. They were greatly disappointed when the processing on 7 million records only took 10 seconds. In the end the client gets an application that runs 2000% percent faster on 20 times as much data. Another happy customer. Another successful FoxPro application. Language Time to Process Convert Mainframe Speed Factor -------- --------------- ----------------- --------------------- Paradox 210 secs 24+ Hours Watching grass grow Access 29 secs (didn't do) Slower than the Post Office VFP 4 secs 20 minutes Greased lightning Todd Landrum is an independent developer in Evergreen, Colorado. He can be reached as ---------------------------------------------------------------------- VFP TIMING RESULTS by Dan Covill At the January meeting, Art Bergquist said he had heard that using the 'm.' prefix made access to memvars slower. Some of us questioned that on logical grounds (the qualification should speed things up by making it unnecessary to check the current work area for a field with the same name), but nobody had any data. So I tried a few timing tests. As usual, the results were not what I expected. First, there is no measurable difference between the time it takes to access a work area field and a memvar, and it doesn't make any difference whether you qualify the name or not. I didn't expect that, but I can certainly accept it; work areas are simply part of memory, and essentially everything is a memvar. What I did find is that there is a big difference between _storing_ a value to a memvar and a field, and that VFP 6.0 is a LOT slower than FoxPro 2.6 DOS at this. Here are some results (in seconds): Action x 10,000 2.6 DOS VFP 6.0 1 Mvar = Value .4 .4 2 Replace Fld with Value 1.2 17.5 3 Replace KeyFld with Value 1.5 21.5 (!) DBF w/5,000 records 4 List Field 1.5 4.0 5 Replace all with 'ABC' .08 .18 6 Index on .20 .20 Tests 2 and 3 did NOT move the record pointer; they were all done on the current record. I expected test 3 to take longer because of checking the .CDX file; but I have no idea what VFP could be doing with the other 15 seconds! Test 4 is what I've seen before; the extra time is due to displaying thru the GUI (Window) interface. Test 5 is another headscratcher, while test 6 is what I would expect. Anyway, VFP 6 is much slower than FoxPro 2.6 in several areas, and about the same in others. I think it's faster on very large files, but didn't test that this time. Don't take my word for it; run your own tests and let me know what you find out. --------------------------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 ----------------------------------------------------------------------