Let’s start with accessibility, because it’s arguably the most important criterion of the three. An accessible document is available to multiple users with a minimum of fuss. Ideally, this means that each user gets the document however s/he prefers to receive it, and its format matches his or her hardware and expectations. Ideally, in today’s net-centric applications and environment, it should also not matter whether the recipient is local or remote.
Notice that this „ideal“ is already available to us in Web browsers. If you and I use different browsers in different operating systems – heck, even if we both use one browser in one OS but we customize it differently – we get completely different views of any content, as you can see in the figure below. Browsers give us both a goal to shoot for, in this respect, and in many cases a delivery system we can use to display output with confidence on any system.
When we’re looking for this ideal of accessibility, along with what we learn from Web Browsers, we can take cues from Microsoft Exchange and similar message broker applications.
By „message brokers“ I mean services that handle multiple forms of message delivery (each form of delivery is usually referred to as a „transport“ service). The broker is responsibility to send a message to multiple recipients, potentially in multiple formats as befits each recipient’s requirements.
If I write a message to Colin and CC Matt and Tamar, I don’t worry about designating CompuServe for Colin, MS Mail for Matt, and Internet for Tamar, assuming I have previously created addresses that indicate how I prefer to deliver messages to these three names. I can add a CC to Nancy by fax, adding a fax number on the fly to designate this fourth transport for the new recipient.
Having done so, I can expect the message broker to initiate the appropriate transport service for each version of the message. Nancy’s fax gets a cover page and appropriate sizing and pagination, my Internet provider gets dialed for Tamar, who receives a message that looks nothing like Nancy’s fax, and so on.
A single document has multiple recipient types and multiple output format types among its attributes
If we take this behavior as a „role model“ for our VFP applications to emulate, we can try to accomplish this goal by handling different types of contexts transparently within VFP. But, better still, VFP applications can hand the whole context and transport problem to some broker service that already knows how to do this. To illustrate the limitations of the first technique, let’s suppose I want to fax from my VFP application. I can use the fax printer driver in an FRX, but there are many attendant problems.:
We can also capture output to a fax printer driver which can save to an image file, and then instruct an ActiveX control with faxing instructions for this captured output, rather than faxing directly.
I’m going to pause for a moment and examine this last fax option a little more closely, because it is rich in illustrative potential (and also because people ask me about this all the time!). Beyond using a dedicated ActiveX control to handle the output created by a Fox printer driver, you may want to have a different application actually send the fax (for reasons that will become clear in the next section). For this to happen, the fax driver has to create a standard, rather than proprietary, image format.
I found several fax drivers that would create standard BMP formats, and I tried telling an FRX that it should go to each of these fax drivers. In each case I encountered bewildering scaling problems. Bitmaps created were generally about 18“ across, and strangely proportioned. I noted that MicroHelp’s FaxPlus driver specifically said that it created images 1728 pixels across, and that this information didn’t seem to „sit well“ with the information I saw in the FRX header. I found that if I altered the FRX header information, I could at least get an image that had a proper aspect ratio and could be faxed as a standard message attachment, although its paper proportions were still incorrect (see figure below).
This is the best I could do, so far, with a REPORT FORM sent to a bitmap format by fax printer driver (note the size of the faxed „page“ in the Wang imaging control window on top and that this was a portrait orientation report). The FRX header information shown is the set that gave me the best results, not what VFP originally saved to the report header.
Mystified by the 1728 pixel requirement, I checked with MicroHelp, who informed me that they had no intention of providing support to VFP developers! (Accordingly, I cannot recommend this product to you wholeheartedly, even if you find that using an ActiveX control like FaxPlus’s to send the fax will suit your application.)
Finally, exploring FaxMan from http://www.data-tech.com, I found some answers and a possible solution, with the help of some good customer support people (thank you Tim! And I don’t even own your product!!). It seems that 1728 is the standard number of pixels for a fax, and this is the size they will all create. At least I could stop looking for one that was different in this respect.
FaxMan creates a proprietary image format called FMF, but Data-Tech explained to me that this format is really a TIFF file, with a couple of bytes changed in the header to prevent people from attempting to fax 256 color TIFF files. Also, the FaxMan OCX and DLLs are apparently capable of scaling images on command for you. It is conceivable, therefore, that you could get good results with these steps:
Think about it. You have to really love your FRXs to go through this much trouble to keep using them!
Having just told you how much trouble I had with FaxPlus, a product that isn’t supported for VFP, it’s hard to recommend a tool that isn’t officially supported by anybody for anything. However, information at www.microsoft.com/kb/ (look for article Q143043, or a file named VB4MAPI.EXE) about VBAMAP32.DLL is so intriguing that I have to add a note here.
VBAMAP32.DLL and the „MAPISendDocuments API“ is a unique option that allows you to get to messaging transports without actually logging on as a user. The KB explains that, „The MAPI DLLs that come with Microsoft Windows, Windows NT, and Windows 95 include a set of BMapi calls that were designed for use with Microsoft Visual Basic versions 1.0 through 3.0. Due to changes in the way Visual Basic for Applications (and Visual Basic 4.0) byte aligns its user-defined types, these function calls no longer work.“ VBAMAP32.DLL is provided instead and, if we can use it in VFP, it might streamline the process of dealing with messaging services considerably. If anybody reading this gets good results in VFP with this DLL, please be sure to report back!
We return now to the examination of accessible documents and messages.
Direct faxing from VFP can be done, but as we’ve seen, it is limiting. If we want really accessible documents we’re probably going to be better off if we tell MS Exchange or the Windows Messaging client to send a message to a recipient who requires a fax, and let the broker worry about how to create the fax image. The fax recipient becomes just one among many more who get their messages in other ways, and all our messages should be sent without our handling the formats individually. You can see that, while the direct faxing method solves an immediate problem, the indirect method (getting a messaging broker to do the fax) opens up whole new vistas of accessibility.
Faxing is actually a special case within messaging transport types, because it always creates an eventual hard copy. This implies that, when your message broker calls a fax transport service, this service will hand off part of its fax job to some additional application or applet, which knows all about pagination and printer drivers (usually a word processor). Even though a paper version is never created at sender’s end of the fax process, this additional application creates the appropriate formatting for eventual hard copy, and supplies this version as a „rendering“ to the fax transport service for delivery.
In the same way, the Internet transport service hands over other parts of its job, such as dialing for Internet access, to applications which know about modems. No application does the whole job.
With this in mind, let’s consider what happens when our primary goal, accessibility, translates to „print a copy on the spot“: our application’s user wants a hard copy of the report, full-stop. A printed copy, in this view of the output universe, is simply a message sent to a recipient who has a local sort of transport.
We already know that our fax transport application „understands“ printed output by asking a capable third party to render printable images for faxes. When we want elaborate printed output, we can do something similar: our VFP applications can call the same capable outside applications to print that the fax transport service would have called for the rendering.
Depending on the situation and the specific capabilities of the printing application, our VFP app will probably do one of the following things:
The last option is probably closest to what MS Fax does, because we do not even know what the application „owns“ the printing process. Using Windows’ registration of file types as classes by their extensions we may just be saying „here’s a document of HTMFile class [or DOC class, or BMP class]. Tell its owner to print it for me, please.“ Context and server neutrality increase accessibility of information.
If you wonder whether all this moving back and forth between applications and services adds complexity to output, it certainly does. But the complexity of using an outside agent to print for us gives us the ability to print more complex compound documents, with different sorts of presentations within it, like the sample message in the figure above. (Note that each file in that sample message might itself contain elements of different formats, all of which will be properly presented and displayed in turn by their host applications.)
I’d like to point out the difference between the report form as an „inside VFP“ container object and other „outside VFP“ containers is not a very meaningful distinction. The rest of VFP probably deals with the reporting elements of VFP as a totally foreign application already! It’s more important for us to evaluate a container on the basis of its ability to host multiple formats well than on the basis of „whether it’s inside VFP“.
Why do we care whether we can produce complex, compound data presentations, why are they worth the extra bother? For one thing, they help us reach our second goal of explainable documents.