When Do You Say Your App Is “Not Supported”?

Do you develop your apps for the least common denominator, or do you provide a set of absolute minimum requirements that must be met in order for your users to install your app?

I have an app that is installed in roughly 750 locations. Of those, nearly two-thirds of the users are still running Windows 98. Naturally, whenever I work on enhancements (and bug fixes) for this app, I have to develop to the least common denominator (in this case, Windows 98). As you can imagine, with the hardware for most of these users I also have to be careful about memory, hard drive space, and dial-up connectivity versus cable/dsl.

Some developers I’ve worked with insist that the absolute minimum OS for their software is Windows 2000, preferably Windows XP, and even more preferably, Windows XPProfessional. I dunno. If I took that approach, I’d lose over 500 customers for this one app alone.

On the other hand, dropping support for the app on Windows 98 would save me a ton of time on testing… One less OS to worry about. And I have to admit, sometimes it would be nice to say, “You’re running Windows 98? Sorry. Not supported on Windows 98.”

When I look at Microsoft’s Product Lifecycle dates, I see that “Paid incident support is now available through 30-Jun-2006” for Windows 98, and I wonder if I should follow the same type of path with the apps I’m developing today.

Do you use Microsoft’s Product Lifecycle in determining your minimum requirements, or are your minimum requirements simply based on what’s needed by the individual app?

Creating a “Fading” Form

I love the Desktop Alerts in Outlook 2003. They provide useful information without interfering with my work. I can’t stand to be working on one thing and suddenly have a MESSAGEBOX appear from another app informing me that it just did something wonderful on my behalf. The Desktop Alerts simply “appear” on my screen for a few seconds, letting me know I have new mail. They even provide some details (name of sender, subject). If I want to read the email immediately, I simply click on the Alert and Outlook opens the message. Otherwise, I can ignore the alert and it will fade away.

I thought something like this would be a great enhancement for some of my clients, so I went about the task of finding out how to make my forms Fade-In, Wait a Few Seconds for User Input, and Fade-Out. I found a solution right away in the Solution Samples that ship with VFP: Transparent Forms.

A couple of Windows API calls can make your form transparent, to the level of transparency you require. The trick to making my form fade-in and out was to add a couple of timer controls to the form. The timers call the SetLayeredWindowAttributes function in a FOR loop, creating the fade-in/fade-out effect.

I put together a simple “splash” screen (you can download it here), which demonstrates the effect. The zip file contains three files: FLASHSPLASH.SCX, FLASHSPLASH.SCT, and 192255.JPG (a gradient JPG that you can set as the form’s picture if you want to).

Two caveats: to create the effects, the user must be running Windows 2000 or higher, and the effects only work on Top-Level forms.

The form contains a few custom properties:

  • lCanFlash: A boolean value (.T. if Windows 2000 or higher, otherwise .F.)
  • nStepUp: An integer which determines how quickly the form will appear (used by the STEP clause in the first timer’s FOR loop). The higher the number, the faster the form fades-in. Defaults to 0.25
  • nStepDown: An integer which determines how quickly the form will disappear (used by the STEP clause in the second timer’s FOR loop). This number must be less than zero! Defaults to -0.25
  • nTransparency: An integer which determines the level of transparency for the form. A value of 25 is a “solid“ form. A value of zero (0) makes the form completely transaparent.

The lCanFlash property has an assign method, which basically DECLAREs the API functions and sets the form as completely transparent (if Windows 2000 or higher). The lCanFlash property is set in the form’s Init() method.

In a nutshell, here’s what the sample form does:

  1. Checks to see if the OS is Win2K or higher. If yes,
    1. Sets the lCanFlash property to .T., which in turn,
    2. DECLAREs the API Functions
    3. Calls the API Functions to make the form completely transparent (invisible)
  2. Turns on the first timer, which uses the form’s custom properties to drive a FOR loop, which calls the SetLayeredWindowAttributes API function — causing the form to gradually appear
  3. Since the sample form is a splash screen, another little FOR loop updates a label control, to make the form look like it’s “doing“ something
  4. Turns on the second timer, which also uses the form’s custom properties to drive a FOR loop, which makes the form gradually disappear
  5. The second timer then Releases the form. The form’s Destroy method issues a CLEAR DLLS command

I have an app which periodically checks a server to see if any of my user’s customer’s have placed orders. If orders are found, they are downloaded for processing, but it’s all done in the background. The user’s typically have no idea an order has been placed unless they stop what they’re doing to either go to a website which shows outstanding orders, or by launching the interactive app.  By adding my own “desktop alerts“ to the system, I can give the user a professional-looking piece of information which shouldn’t interfere with their work.

Hope you like it. Since this is my first attempt to share something with the FoxPro community, any feedback would be greatly appreciated. Once I get done with my “desktop alert“ system, I’ll pass it along.

Sample Form Download

Edited: Probably best to try this out in VFP 7,8 or 9. It’s been so long since I’ve actually “used“ VFP 6, I forgot about the hoops you’ll have to jump through to make this work (like HWND). Thanks Fred for your feedback! – Kevin

A Blog Is Born

After spending the last twelve years with my head down (code, test, debug — repeat), I’m finally taking the plunge and sharing my experiences and thoughts (and maybe a few rants and raves) with my fellow Fox programmers.

Whenever I’m asked why I’m still using Visual FoxPro as my primary development language, my answer is always “the FoxPro community is the best.” Odd that I’ve never stepped forward to “join” the community I care so much about.

This blog is my first attempt to move into the neighborhood and say “Howdy” to all my FoxPro neighbors.

Thank you Eric for providing this excellent resource!

Stay tuned…