Desktop Alerts Tip: Building App-Specific Alert EXE’s

When I first wrote the Desktop Alerts, I pictured a perfect world where everyone had one set of VFP runtimes and the Desktop Alerts would be installed, once, on every computer in the world.

Alas, the world is not perfect. Some apps install VFPALERT.EXE to the app folder, some do not. Some developers add new functionality and recompile the VFPALERT project, some do not. Some recompile it in VFP9SP2, some do not.

To make things easier on yourself and your fellow developers, I recommend compiling your own application-specific version of the Desktop Alerts for each application, and including it (along with ALERT.WAV) with your installer.

Let’s say I’ve written the following three software products, and I want to include Desktop Alerts functionality with all three:

ABC Accounting
BCD Bookkeeper
CDE Customer Manager

On the one hand, I could install the Desktop Alerts to one specific location, and all three products would use that one install.

But, if my customer is using software from another vendor that also uses the Desktop Alerts (and, especially a modified/recompiled version), I may not get the same functionality I expected.

So, since I have three different products, I’m going to create three versions of the Desktop Alerts COM EXE Server, and install each one with its respective product.

MAKE SURE TO SELECT REGENERATE COMPONENT IDs IN THE PROJECT BUILD WINDOW IF YOU ARE DOING THIS!!!

Build Dialog in Visual FoxPro

 

I’ll take the original source code (from the VFPAlert.zip file from VFPX), and compile it three times (with new Component IDs for each one) using the following filenames:

ABCALERT.EXE
BCDALERT.EXE
CDEALERT.EXE

Then I can distribute each one with their respective product.

In the ABC Accounting software, I would use:

oAlertMgr = CREATEOBJECT(“ABCAlert.AlertManager”)

Instead of the usual “VFPAlert.AlertManager”.

This also frees me up to recompile the alerts in VFP8 (if my app is written in VFP8), without having to rely on installing VFP9SP2 runtimes along with my app just to support the alerts.

All I need at this point is to add ABCALERT.EXE and ALERT.WAV to my ABC Accounting app installer (and make sure to run ABCALERT.EXE with the REGSERVER flag during the install) and I have an all-new, app-specific version of Desktop Alerts just for my app – without having to worry about another vendor’s application “taking over” the Desktop Alerts.

Desktop Alerts 1.0.0 (Production Release)

After 4 years in beta, I’ve posted a new version of the Desktop Alerts as a Production Release on VFPX.

You can download the latest source code and whitepaper at:

http://vfpx.codeplex.com/releases/view/79034

The new version includes a couple of changes/enhancements for improved Vista/Windows 7 compatibility.

There is a new property for the AlertManager class: cSettingsPath. This property can be filled by calling the new AlertManager method SetSettingsPath. Send in the full path of a “writeable” folder where the settings file should be written (DACONFIG.XML).

Another new property of the AlertManager class is lCleanMemory. The default value is .F. – if you set this value to .T. the AlertManager will attempt to reduce memory consumption by calling some code I stole leveraged from Sergey’s blog.

I also updated the Settings window to default to Segoe UI, 9.  There are new settings in the VFPALERT.H file which can hold “fallback” font name and size for users on earlier (pre-Vista) versions of Windows.  The include file currently uses Tahoma,9 as the “fallback”.

I’ll be posting some new notes on the Codeplex site tomorrow. Basically, a FAQ sheet that answers some common questions about installing, etc.

Enjoy!

Updated: Special thanks to Rick Schummer for the friendly reminder to release, and Art Bergquist for editing notes from the original whitepaper!

Updated Desktop Alerts Source Code Available

Links in this post have been updated to link to the VFPX site on CodePlex.

I’ve updated the source code for the Desktop Alerts, and posted to the web site.

Updates include the ability to hide the Close button and Push-Pin button on the alert form, and I made a couple of minor changes to bring back the ‘fade-out’ effect when the alert form releases.

You can get the updated code here.

A single zip file. When unzipped, it should create a single folder named VFPALERT. All files for the project are in the one folder.

I’ve also posted a Sample form, which allows you to select/enter the parameters for an alert and click an ‘Alert Me’ button to view the alert. Very easy to make minor modifications to an alert and quickly see the results.

The download includes a program file named TESTSAMPLE.PRG, which contains three class definitions for “callback” objects.  The sample form includes two “pre-defined” alerts and a third one call “Create My Own Alert”. After selecting an alert and setting the values for the parameters, the Alert Me button calls the AlertManager’s Alert() method, runs the Alert’s SetCallback() method (passing in one of the three “callback” objects), then issues the Alert method.

The Sample form also comes with a COMPILED EXE (VFPALERT.EXE). Simply run the EXE with the /regserver switch, then DO FORM pathsample from the VFP Command Window.

Please note: this EXE was compiled with VFP 9 SP1. You will need the VFP 9 runtime files to run the sample. The runtimes are not included with the download.

The sample form and compiled EXE are also available here.

A quick note of SPECIAL THANKS to the Chicago FoxPro Users Group for allowing me to come to their meeting this past Tuesday to talk about the Desktop Alerts. I had a GREAT time talkin’ FoxPro, and enjoyed meeting all of you!

Special Thanks also to Patrick O’Hara for taking my son & I out for some Chicago pizza (and for showing me some fantastic dev tools he’s written) after the meeting.

This post originally appeared on the Foxite Weblogs site.