Here I will attempt to explain how you can change logos on the fly using nothing more than a piece of information from your data file.

Determining What You Can Key On

The first thing you need in your data file is something that you can use to determine which logo/address/whatever block you want to use. Whatever this is, you have to be sure that you know what all the possibilities for it are. We can get around nothing being there, but we can’t get past an entry you didn’t anticipate.

So here are some good places to look:

• Warehouse or Plant codes: Things like “MP”, “ZX”, “BQ”, etc.
• State or Provice: TN, MO, CA, AL, NL and so on.
• If things are numbered, so much the better.

If you don’t have any of those, all is not necessarily lost. Some places will use different company names. If you have “John’s Radiator Service”, “Eastside Plumbing Corp.” and “United Radiator Supply” you could use a TDF (transformation) to extract just the first 4 characters and end up with “John”, “East” and “Unit”, which will work just fine for our purposes.

The main thing to remember here is that whatever you pick should indicate which variation you need to be printing, and it can’t have any spaces in it.

For the scope of this sample, I won’t describe how to make a TDF to do this. I will assume that we have a data file with a field in it already that contains the information we need. And we’re going to use three plant codes for our examples: “P1″, “P2″ and “P3″. I’m going to call this tidbit of information our “Key”. Pretty simple.

Getting That Into a Variable

To be able to print a form with a variable logo on it means that our logos will have to be on subforms. There are other ways to do it, but this is the simplest and works well anywhere up to about 20 different logos/address blocks…so that’s what I’ll explain.

You need to get your Key into a variable that will be available no later than the subform with your logo on it will need to be printed. This could be by the end of the first page (if you intend to place the header last before going to the next page) or it could be at the start. My personal preference is to incorporate the variable as it is needed on the very command line to JFMERGE. That way, it is available even before the form itself loads, so we’re guaranteed it will be there when we need it.

That can be difficult in some circumstances, though, so I’ll describe how to do this with just a global variable and some preamble code…and we’ll drop the page header at the end of each page, and at the end of the job. This method is also adaptable to using multiple logos in a single print run.

Making Your Global Variable

There are two common ways to create a global variable while your form is running.

The first is to use a command like this in your FNF data:

Or you can do this, which does the same thing:

The second is to put your data into a field that has its Global attribute set:

If you double-click on your field, you can see the button to switch on the Global option here:

Field Options in Output Designer

The trick if you use the field method is that the field must be hit before you need the variable to place the changing section.

Creating Your Changing Subforms

You will need to create a subform for each and every possible code that you will encounter. I also recommend making one that will appear when your chosen code is empty. It will happen, and its best to print the “default” logo and/or address than to print nothing or – worse – throw an error.

For our sample, you would create four subforms with these names:

To maintain your sanity, make all of these occupy the same amount of space on the page. So, if P2 has the biggest logo and/or the longest address, make all your subforms that size and allow for that much space to be used at the top of your pages.

I find it useful to draw a box on my boilerplate (JFMAIN) page that takes up the required space. Just set it to no fill and invisible outline and you’ve got a nice dotted-line box that will not print. You can then create each heading right there and then copy/paste them to other pages to make subforms of them.

Calling Your Logos

I’ve made the decision here to demonstrate how to call the header at the end of each page. That makes this easier, but it has its limits. My hope is that if you need to do this another way you’ll be well enough equipped to try it.

If you have managed to get your Key into a global variable and you’ve got a newer-style form that has a SWITCHPAGE event in the JFPREAMBLE_1 docvar, then you can override that event with another one that will drop your logo and then switch the page.

A standard SWITCHPAGE looks like this:

And we’ll copy that across to the override section of our JFPREAMBLE and edit it to look like this:

positionabsolute
This inline text text control command tells JFMerge to place the “pen” where it will place the next thing it does at a specific point on the page. You can get this measurement by getting to coordinates of that invisible box you drew, or you can put a field there and use positionsave and positionrestore to get the same effect. If you were going to put this together as a set of standard paste-in functions for a number of forms, you might go with that instead.

@global:
This construct definitively calls for a global variable of a specific name. In our case, that’s PLANTCODE. You could use @PLANTCODE. and get the same effect, but I feel the inclusion of the word “global” eliminates any possible ambiguity. It’s a style thing.

A note about my syntax: You will notice that in my preamble code I always type the names of variables and field names (things I have decided) in UPPERCASE, and all reserved words, commands and so forth are all in lowercase. I do this from habit, but you cannot argue that it doesn’t make a tough preamble easier to read.

What About the Last Page?

You may well ask what happens on your last page, when there is no page being switched to, there will be no SWITCHPAGE fired and therefore there will be no logo. Add an event like this to your JFPREAMBLE:

The JfEndData!EndData group will only ever fire once for every data file that you process. It will be the last thing that JFMerge will fire when your data file comes to an end. For our purposes, this is perfect.

Samples

Of course there are samples! I’ve created a data file and a couple of forms in Output Designer 5.6 that demonstrate these concepts, and that should actually work. Now that you’ve read the article (you did read it, didn’t you?) you can download the samples. I’ve put some comments in them to help you along. There are two data files that show how a single logo selection works as well as how you can change the logo even as you move through the data file.

Click here to download the samples that go with this article.

More Complex Exercises

It is possible to use more than one key to determine which logo or address you should print. You could use a combination of a plant code and a country code, for example, and end up with subform names like this:

What you really need to remember if you decide to do this is that your number of combinations can quickly spiral out of control. If you had ten plants in 3 countries, that’s 30 combinations right there. Then you’d need to create LOGO__US, LOGO__CA, LOGO__MX, LOGO_P2_, LOGO_P1_ and so on and so on to allow for possible empties.

In such a case as this, I’d recommend trying to come up with something else to use as the Key. Really, I would.

If you must do something like this and you can keep your 2 keys separate (say you have a code for the address and another code for the logo), then you just create subforms for logos and subforms for addresses, and use them both. Not too hard that way.

As with all things JetForm, there are probably more than a dozen perfectly good ways to do this. This is just one of them.