Hi,

We are experiencing what I think is an issue using the Print Screen (APRNTSCRN) function in ATE. When selecting a printer (via APEX) with the exact same name in Windows as the PQI file, it appears that the configuration from the PQI file is used. In our case, this results in the GDI directives being sent directly to the printer without pre-processing. We often install printers in Windows but use passthrough in that printer's PQI file. If needed, the user can select a Generic Printer (GDI) option on our menu which uses PROMPT: to send a GDI printout to that same printer (which avoids the use of the passthrough PQI file.)

It appears that this behavior changed sometime post ATE 6.5.1631.3. It can be reproduced in ATE 6.5.1660.7.

I haven't tried this specific version but noticed some AUXLOC: related changes in the dev notes for version 6.5.1633.5. Perhaps this is actually a result of that improvement?

Thanks,
John Andreasen

Hmmm....

The change in 1633.5 that would affect the Print Screen was to look for an ASHCFG:PROMPT.PQI or SYS:PROMPT.INI file in the case where the requested printer name was "PROMPT:". (Normally it would not try to find a printer init file corresponding to a printer name that contained characters illegal in a filename.ext, such as colon.)

It's not clear to me whether you have a PROMPT.PQI file, but even if so, that doesn't sound like the issue, since your PROMPT.PQI would presumably be set for GDI printing.

It's also not clear to me that A-Shell or ATE would ever have bypassed a printer init file whose name matched the Windows printer name used in a SPOOL operation. So I'm pretty well confused by this.

My suggestion would be to activate the LP trace from the ATE Debug Message Window, and then make a note of which traces went with which APRNTSCRN events (i.e. clicking the print button in the APRNTSCRN dialog, then clicking one of the print options in the APEX dialog.) Maybe that will shed some light on what's going on here.

I should add that Ty has recently registered a few unrelated complaints/suggestions for improvement to APRNTSCRN, so it looks like I may be spelunking around in that code in the near future. If anyone has any related suggestions/complaints of their own, this would be a good time to register them.

We do not have a PROMPT.PQI file.

Further testing reveals that the change occurred between 6.5.1639.3 and 6.5.1649.6. I enabled the LP trace. While the traces are different, I am not quite sure they are meaningful. Perhaps if you have some time, you could take a look. I will send them to you for reference with the client side PQI file.

By the way, where do we post suggestions for APRNTSCRN?

Traces received, thank you. (I'll have to study them later, probably getting back to you on Friday.)

As for APRNTSCRN suggestions, how about this thread: APRNTSCRN refinements

First, thank you for the very nicely organized and annotated traces which made it very easy to zero in on the differences.

Second, it happened in 1640.0 (so disregard my comments about the 1633.5 patch). But the aspect of the change affecting you isn't quite captured by the description in the release notes:
Finally (and perhaps unfortunately, considering the negative effect on your situation), I'm not convinced that the current behavior is wrong, or if it is, how to resolve it for you without breaking it for someone else.

In the most general terms, APEX suffers from the inherent tension between letting users take control of printing vs. letting the application have its way.

To get more specific, the problem which 1640.0 fixed (even if the release notes didn't explain that) was that of trying to preserve the relevant configuration settings from the original PQI file (corresponding to the printer name passed by the application in the XCALL SPOOL) when the user selects a different printer. For example if the application specified a logical printer with a certain character size specification, say 100 columns by 72 lines, but the user then selected a different printer from the APEX printer selection menu, most likely we would want to try to preserve that 100 x 72 layout for the new printer.

The way that was accomplished was to pass the print request back through the "front door" which contains the logic to a) start with the settings passed in the XCALL SPOOL (directly from the app or indirectly from APEX), and b) load the PQI file for the new printer if there is one.

Since 99% of the time, Windows printer names do not match up with A-Shell PQI names, we typically ended up getting the benefit of (a) and not (b) in the above procedure.

But in your case, the fact that you've renamed the Windows printers to match the A-Shell PQI names, selecting a new printer from the APEX printer selection dialog results in processing the new PQI.

It's impossible at this point to intuit the degree to which any special configuration settings intended by the application should be maintained or override those that are part of the new printer's configuration, or the extent to which the operator is even aware of the possible conflicts. For example, the application may have wanted a certain paper size and therefore a printer name whose PQI specified that size and/or the corresponding BIN. When the user switched to a new printer, presumably they didn't want to change the paper size, but maybe the corresponding BIN is different in the new printer. Or maybe the printers have different setup commands which are invoked by a PREFIX reference in the PQI file?

It's just not obvious which is the best approach here, but it seems like when it doubt, it makes more sense to process a PQI file that corresponds to the requested printer than to ignore it.

I can think of a couple of possible approaches to splitting the difference, but I'm not sure I fully understand the subtleties of your setup. One idea would be for APEX to automatically set PASSTHROUGH=OFF whenever printing. (The whole concept of APEX kind of falls apart when it comes to dealing with printer-specific ESC sequences, since there's no way for APEX to know how to represent the result visually; what would be the value of a preview otherwise?) But, APEX can still be useful in apps that use PASSTHROUGH printing, by temporarily switching to GDI printing and applying some common-sense defaults to the font size logic, i.e. try to shrink the to fit width of the paper. You can then see a reasonable facsimile of the output, and if you decide to print-as-intended, it can switch back to passthrough mode to get the exact result you would have gotten without APEX.

Another idea would be to add yet another SPOOL switch to explicitly tell A-Shell to not look for the PQI file. APEX could specify that switch when printing from the printer selection dialog. But that would only be needed in the case where the Windows printer names matched existing PQI names. Which leads back to the question of why you set it up this way in the first place. The only real benefit I can see to matching names is exactly the one you're trying to avoid, i.e. being able to work backwards from the Windows printer name (when selected externally by the user) to the corresponding A-Shell name and PQI file.

As always, I'm open to suggestions.

Thanks for looking into this.

Let me explain a bit about why the printers are set up as they are. We have a program that installs Windows printers for us from configuration information in A-Shell. At that time of that programs writing, it seemed like a reasonable (and clear) approach to name the printers exactly the same in Windows as A-Shell. I did not think about it causing a problem like this.

I understand the reason for processing the PQI file from APEX. I can see situations where it makes sense. Perhaps adding a flag to not process the PQI file or at least ignore it if it contains the PASSTHROUGH=ON option would be reasonable.

Without something like this, we would need to change the way the printers get named from that program. While that is possible, we already have many printers installed in the field using this scheme.

I'm fairly sure that the new behavior (processing a PQI file if it matches the Windows printer name selected from the dialog) is desirable in at least some cases, the only good way to disable it that I can think of is via a switch of some kind.

The question is where to put the switch so that it can be easily activated without having to modify a lot of programs.

Adding it to XCALL SPOOL seems like it would require virtually every program to be modified to send the new switch.

A client-side environment variable might be simpler, since you could set it, once-per-session, in your start-up command file (using AG_SETENV or AGCMD.LIT ). It would still require all the ATE clients to be updated, I'm not sure any solution can avoid that.

Or it could be added to the ATE configuration, which the server could also update, once per configuration.

Do any of those sound like an acceptable compromise?

Either of these options would work for us. An ATE update would be no problem as we put our desired ATE version in the atesetup directory on the server.
We could also handle a new parameter for XCALL SPOOL as most all of our spooling is done from one include file. Perhaps that is not true for other A-Shell users though.

Stephen and I were discussing this and were wondering if it would be possible for APEX to judge whether or not a specific printer's PQI file is suitable for the print job? For example, if it is known that a printout has GDI directives and a printer's PQI file has PASSTHROUGH=ON, then it could be ignored. If it is not a GDI printout, that PQI file would be used.