Shedding Some Light

In an effort to entice you to sit in on my Extending the Sedna Data Explorer session I have recorded a short teaser video, and have it posted on the Southwest Fox Video page. The same session will be given at the German DevCon in November.

Please take a look and let me know what you think.

We all take things for granted and I recently found renewed appreciation for the VFP compiler catching simple things. Over the last week I have been working on and off to track down an indexing issue brought to my attention by one of White Light Computing’s sub-contractors. It is an issue between VFP and FoxPro for DOS.

One of my test programs runs in FoxPro 2.6a DOS and had the following code:

llSeek1 = SEEK( “CRANE “, “test”, “lo_locn” )
llFound1 = FOUND()
llEOF1 = EOF()

I posted the code for a code review and it was revealed to me something I know: FoxPro 2.6a does not support the third parameter for the SEEK() function. FoxPro 2.6a for DOS and FoxPro 2.6a for Windows happily accept the line of code and ignore the extra parameters. I guess the FoxPro compiler figures this is a mistake on your part and is doing you a favor by ignoring the problem. In my case it was bad because I did not have the proper index tag selected and I was getting misleading results.

In VFP, the compiler catches extra parameters. If you add a fourth parameter to the SEEK() function VFP provides you some responsible feedback.

Compiling d:\devvfp9apps\junk\program1.prg
llSeek1 = SEEK( “CRANE “, “test”, “lo_locn”, “more?” )
Error in line 23: Too many arguments.

Compiler rules being tighten does cause pain initially, but in reality this is one of the best things the Fox Team did for us over the many versions released. I work in several versions of FoxPro and VFP these days, and understand the tweaks on the syntax is something I get burned on once and awhile. I really appreciate when the compiler saves my bacon.

One of the other things I commonly see with code I am working on is the ENDIF comments. For instance, sample code:

IF llCondition
llQueryOK = .T.
ELSE
llQueryOK = .F.
ENDIF llCondition

Initially looking a the ENDIF one might think this is invalid syntax (ok, maybe I was the only one {g}) and the developer forgot to put in the && inline comment. In reality, FoxPro knows there is no valid syntax after the ENDIF so the rest of the line is completely ignored at compile time. This happens in all versions of FoxPro.

We have been taking on quite a few projects over the last year and my preference is to recompile to VFP 9 so we support fewer versions of VFP compilers and runtimes, and I want to take advantage of the stability of VFP 9. The most common compiler error I see is the lack of commas separating variable declarations. This one drives me crazy. It is easy to fix for sure and VFP 9 is really good about pointing out the problem.

I am doing some research on a strange index issue today (likely a future blog post). Googling almost anything in VFP will link you to the single biggest FoxPro KnowledgeBase on the planet: Steven Black’s hosted Visual FoxPro Wiki. I wish I had a count of the number of times I visit the Visual FoxPro Wiki.

Today the topic I found extremely compelling is “CDX Corruption Checklist“. It is already marked as a three-star topic (highly rated). This topic did not help me solve my problem, but it was an excellent read.

My thanks to all involved in putting this one together.

One of my clients called me with a problem with one of their VFP 6 applications crashing. The application has been running in 30 locations for 10 years with very few changes. I did not develop this particular app, but did mentor the original developer and helped with the design. It is used by engineers. At the site it was working on one computer, but not the other three. The error is one of the more common ones: Function argument value, type, or count is invalid. (11)

The IT department no longer has fresh VFP expertise because they have moved on to a new development platform. They gave me a call hoping I could fix it immediately so the engineers could keep on working. They brought the data back, but could not reproduce the problem.

Fortunately the Visual MaxFrame error logging is decent. Unfortunately the customer does not compile in the debug code so I could determine the program, but not the line number or the actual code. I dug in using the error log and traced the code to the SYS(3050) command. In the startup of the application a call is made to a procedure that sets the amount of foreground memory to a percentage of the overall memory available on the machine. The calculation uses Windows API calls to get memory on the machine and then works through a formula. In this case we are talking about three new engineering workstations and they were loaded with 4GB of physical memory. The program was determining it could have a little more than 2GB of RAM. The VFP Help file does not indicate a limit even in the latest version, but apparently there is one.

So the lesson learned today is: do not to allow the setting of the SYS(3050) function be strictly calculated. I added code to pick the minimum of the original calculated amount and something less than 2GB. It is the first time I have used the VFP MIN() function in a long time.

I never hit this problem because I have a configuration item with the amount of memory to set. I know several developers use a formula to determine the amount of memory to allocate to VFP. If you are one of these developer you might want to check your formula to see if large amounts of memory could trigger this error.

I was working with one of my clients a couple weeks ago and he asked me my thoughts on using a Config.FPW with a VFP app. I mentioned I include one with every application I deploy and sometimes two.

The first one is brought into the project, marked as included, and compiled inside the EXE. Some Developers shy away from this technique because it makes the Config.FPW read-only and this sort of defeats the purpose of a configuration file. This was true in VFP 7, but since VFP 8 was released you can have more than one by including the following line in the Config.FPW:

ALLOWEXTERNAL = ON

You can include a Config.FPW file in the application folder to override any of the settings. Visual FoxPro gives the external file priority. Here is my default Config.FPW file I start with for all my applications.

* Default Configuration file for application
SCREEN = OFF
RESOURCE = OFF
ALLOWEXTERNAL = ON
_BROWSER = “”
_BUILDER = “”
_FOXREF = “”
_CONVERTER = “”
_COVERAGE
_GALLERY = “”
_GENGRAPH = “”
_GENHTML = “”
_GENMENU = “”
_GENPD = “”
_GENSCRN = “”
_GENXTAB = “”
_TASKPANE = “”
_TOOLBOX = “”
_TRANSPORT = “”
_WIZARD = “”

You might be wondering why I have a bunch of the system memory variables blanked out. I cannot recall where I read it, but this helps a run-time application start faster because VFP is not trying to find the IDE tool locations determined by the system memory variables. This has been an old trick from a long time ago. We are probably talking nanoseconds of savings because VFP is very fast, but I only really had to type these in once.

So my client implemented my idea in his app and called me back to tell me I was nuts because it was not working. Crazy talk, I know I have been using this for years. I asked him if the file was marked included, and if there was actual settings in it and he proclaimed yes. So I connected up to his machine to see what was up. He included it in the Programs section, not the Text Files section in the Project Manager. Took me about 30 seconds to figure this out and he was back in business.

I do find it interesting that Fox cares about this as I always thought it was the file name extension that mattered, but apparently the section you include the file under does have an impact on how it is treated. Good to know (and share with all of you just in case I am not the last developer to learn this {g}).

I have read where some developers are using this file to SET REPORTBEHAVIOR 80 so they can move their apps to the VFP 9 runtimes without needing to change their source code. I have an application object that calls an environment settings object to make most of the SET commands the way I like or need them for my applications. Alternatively you could set them in the Config.FPW, I just don’t use it this way.

I also read something interesting this week about the Config.FPW file that I had not considered before, but if you include a Config.FPW file in the same folder as the Visual FoxPro OLE DB driver it will use your customized settings. I have not had a whole lot of use for the OLE DB driver in my Fox projects, but it is good to know in case I do have the need to do so in the future.

What techniques are you using to help me build a better default Config.FPW?

I can probably count on both hands and feet the number of times I have literally sworn at Visual FoxPro (that would make it an average of once a year). Today was one of those days. I have been working on a new solution for one of my customers that needs to send email. I have tried several techniques with emailing from FoxPro over the years (Outlook Automation, CDO, West Wind wwIPStuff, Shelling out a MailTo, and most recently Craig Boyd’s Extended MAPI FLL, and Blat). The swearing has nothing to do with any of the email techniques, but I can say working with email does cause hair loss.

The situation that caused me to swear today was one I have never seen before, and honestly cannot explain how it happened. I was working with a set of classes. One parent class (abstract) and four different subclasses with all the different implementation scenarios. I was using the Class Browser to work with the class library. I instantiated the child class like normal using a NEWOBJECT(), and then called the SelfTest method I have setup to run through different test scenarios I have to verify the code works as designed. I found the problem I was tracking down in the debugger, canceled out, and opened up the subclass.

This is when the twilight zone moment happened. When I opened the class all the source code for the class was gone. I mean gone, as in zero property settings, and no method code. I closed the class and opened it again. Same thing. Holy S&^*&&*t! (sorry, but I have to tell the whole story). A complete morning’s worth of stream of conscious coding out the window. I tried to open up the parent class and got the message that the class was in use. Weird.

CLOSE ALL
CLEAR ALL
RELEASE ALL
CLEAR PROGRAM
ox=.NULL.
RELEASE ALL
*{pray}

Yes, I know the commands have some redundancy, but one can never be to sure to get the cleanest environment. Back to the Class Browser and still no luck opening the parent class: still in use. Visual FoxPro has a way to hold on to classes when I least want it to. Time for the FoxPro flush (not the FLUSH command, rather, QUIT and restart). Opened up the Class Browser and my subclass and there it is in all it’s glory, the source code for methods and properties are back to normal. Relief.

So I backed up the class library and finished up the documentation in the classes and called it a morning. Hopefully the stress of potentially losing the source code made me stronger since it did not kill me (this time at least).

I was mentoring one of our clients this morning because of a reporting issue he faced with some weird truncating labels (not that this tip is of any help for his problem {g}). During the session he showed me this new wiz-bang function he created to concatenate text together to be displayed on the report. He mentioned how his function removes the missing details from a snail mail address. You know the drill, customer wants to track address line 1 and 2, contact name and company name, but only wants to print the things that are filled in.

I turned around and told him about his new friend the semi-colon (;). This is a trick I learned back probably in FoxPro for Windows or even DOS when I was creating labels for customer mailings. You first drop a textbox on the Report/Label designer and size it to show the max lines you will print based on all the data being entered in the record. You can add the expression like this:

cCustomerName;cCompany;cAddress1;cAddress2;ALLTRIM(cCity)+”,”,cState,cPostalCode;cCountry

The semi-colon acts as a carriage return and any columns in the expression that are empty are not printed and if the line is empty the carriage return is not included. The commas (,) outside of a quote are replaced by spaces. So you can see how I am concatenating the city, state, and postal codes for a line.

I know this is an old trick and tip, but my client has been using Fox of some sorts for a long time too so in the case where you did not know this I am hoping it will be helpful. There are so many little things like this I take for granted that everyone knows, but realize in working with other Fox developers that this is not always the case. I also wonder from time-to-time how many little tips like this one I don’t know about.

On May 1, we announced the speaker and session lineup for Southwest Fox 2008.

Menachem Bazian, Rick Borup, Craig Boyd, Bo Durban, Mike Feltman, Toni Feltman, Tamar E. Granor, Doug Hennig, Andy Kramek, Andrew R. MacNeill, Barbara Peisch, Cathy Pountney, Rick Schummer, Alan Stevens, Rick Strahl, and Christof Wollenhaupt.

It was even harder selecting from the outstanding list of proposals this year than it was last year, and Doug, Tamar, and I are very excited about the sessions being presented this year. There are some killer topics such as taking advantage of GDI+ in your VFP applications, creating custom report controls, profiling and refactoring code using the VFPX Code Analyst tool, using WMI, taking advantage of the Sedna Upsizing Wizard, using Ajax and jQuery in Web applications … the list is long and exciting!

More details can be found on the Southwest Fox Web site and our blog.

Registration is now open, so be sure to sign up today for a fun three days in Phoenix in October. Even better, if you register before July 1, you save $75 on the registration and get a free pre-conference session, a $99 value.

We’re looking forward to seeing you in October! Only 165 days until we meet in Mesa…