Can VFP9's report engine still process .frx hacks 1

[stanlyn]

Hi

Can VFP9's report engine still use the old style .frx hacks for granular reporting. In a kiosk style of app, I need to NOT allow the user to select a printer, or copies and etc. I need to handle the printer selection, copies, duplex, color, collation, size, landscape/portrait settings all from the options table where only a user with admin rights can change.

Mike's article from

http://www.ml-consult.co.uk/foxst-12.htm

kind of says yes, so before testing later, I thought I'd ask for a quick and definitive answer. I've also read many other articles that says the new vfp9 engine does not use those values anymore. Is this true?

My old vfp7 app is ignoring the hacked settings and prints where it wants on a Win7,8, and 10 machines. I have examined the .frx files and actually see the hacks being done, however printing is still unpredictable. The printers are network printers and using their crazy port numbers, so I changed them all to short names with actual ip addresses, and still unpredictable. I'm testing on a Win10p machine. What else should I be looking for?

Thanks,
Stanley

 

[Mike Lewis]

Hi Stanley,

The short answer is: Yes. With regard to the FRX hacks you mentioned, VFP 9.0 behaves exactly the same as in earlier versions.
The big difference is that in 9.0 you no longer need to rely on the hacks. You simply make the required settings from within the report designer, and then save the printer environment within the report (tick the Printer Environment option in the Report menu).

This is explained in the very last paragraph of my article. What might be confusing you is mys statement that "printer settings are no longer saved in the FRX". But that only refers to the default situation. Provided that option is ticked, the settings you have made will be saved, and there is no need for any hacking.

As for why your printing is not working on a Windows 10 machine, I don't know the answer to that, but I don't see how it could be anything to do with the issue we are discussing here. It's more likely to be a printer driver issue. Have you tried testing it with a local printer rather than across the network?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

First of all, I would ask you to clarify how you interpret the situation.

Mike, in short, says you don't need to hack the EXPR field of the first record and empty it because you now simply have an additional setting here in report properties:

So when you absolutely want to store printer info into the FRX, you can do so. This switch allows that. that also means the same EXPR field is still used for that and you can modify its content.

The big point is, it's inferior to what you can do going the other recommended route of solving the need for multiple printer configurations, each one for a report: You install the same printer multiple times in Windows itself, give it several names and therefore have several configurations you can then switch simply by switching printer name, which within VFP means to SET PRINTER TO NAME some_printer_setting_name.

So let's say you have an HPLaserjet with 3 printer trays and put in normal, high quality and label paper into the trays, then install the driver thrice and name it HPnormal, HPHQ and HPLabels and configure these three logical printers (all the same physical printer) to use paper tray 1,2, and 3. The big advantage here is you can use absolutely any detail the printer driver allows you to set. In contrast, the EXPR field of the first record of an FRX can only contain a subset of configuration options, simply by the fact of merely storing a set of textual key-value pairs in a memo, this is limited, as far as I know. and I know there is SYS(1037), which behavior got changed with XP and SYS(1037,2) and SYS(1037,3) to read printer settingsm into FRX and FRX settings into the default printer. But that doesn't cover everything and is limited to the default printer.

To work this way means you never use this setting to actually save the printer environment in an FRX. So when you ask me, that VFP option to choose saving or not saving printer options came far too late. At an earlier time, the way to store such info may have been enough, but printers and their drives have become more complex and possible options, too.

You might consider this as separation of concerns, which are actually only one and should not be separated, as here you don't have separate concerns of printer configurations and reports, they must match to work out correctly. Yes, but it's also unfortunate to need to exclude FRXes to hack them with different settings and rely on the printer system getting and setting them.

So overall, you may give it a try, but the solution of multiple printer installations the VFP community already used for very long is much more near to what Windows offers to both users and printer vendors. This compares a bit like using ODBC DSN (Datasource names) and make all detail configurations in the ODBC Administrator instead of using a connection string you can keep under your control, which is the only part speaking for saving printer environments. But the disadvantage of your customers in control of the printers via Windows Printer system or the connection settings via ODBC Administrator also is the advantage they can correct or switch, when necessary.

The only remaining disadvantage is you have to SET PRINTER TO NAME x before running a report, but you have a report code section, too, within the report data environment you can embed the SET PRINTER TO NAME some_printer_setting_name in the Init of it.

There also is no worry about changing the default printer, as SET PRINTER TO NAME printer_name only changes which printer VFP uses to print, it doesn't change the Windows default, so you also won't need to reset it.

The final thought perhaps: As you don't embed the configuration in FRX you have to do this for every customer and add an administrative burden for them, but then you'd need to adapt your FRXes to other customers, too. So this seeming disadvantage isn't one, it's even contrary: You can use the same FRX without settings just depending on a certain printer name, which several customers can give their own printer install independent on the printer make and model, just supporting the options your report needs. So, in the end, separating configuration from reports now has an advantage and concern: Several customers having different printers with good enough similar capabilities to be used.

Bye, Olaf.

 

[Olaf Doschke]

Windows 10 has one very unfortunate setting in regards to printers, contradicting the meaning of default printer: It sets the last used printer as the default.
Working with SET PRINTER TO NAME will make this harmless.

Otherwise, I don't know a behavior already starting from Windows 7 onwards different from XP or Vista Windows printing, but maybe it just shows the inferior nature of EXPR hacks. Use the multiple logical printer names solution and this should work out fine.

Bye, Olaf.

 

[stanlyn]

Hi,

If there is a configuration in the .frx and I configure the report and tick the "save environment" checkbox, 1_which would be used? 2_if both, then who has priority? 3_if not both, then which one gets ignored? I'd like the configs be as simple as making the selections in the attached form, without the need of creating different printers for different settings for each report and customer. The button beside the printer name is populated from the aprinters() function.

I'm not totally sure how I wrote this vfp6/7 app back in 1998, but I'm pretty sure I used the "set printer to name printer_name" and then I modified the frx from their selection of options listed here, and it just worked. No need for different named duplicate printers or special configuration of the report. Heck, back then I did not include an option to fire up the report editor to modify the report. The report never needed to be modified during or after the install, or printer change, or anywhere. It is this behavior I'm trying to keep with Vfp9 and Win10...

Here is what I done 15 years ago in the vfp7 app and has worked reliably through the years in WinNT, Win2000, and WinXP, which now is causing issues in Win7 & 10. Notice that only an admin can set those settings (the administrative menu item is active) while regular users have no control as to where the reports are sent to, nor their copy count.

Currently, I'm updating this old vfp7 app to vfp9 with a sql backend, and still have the need to control all aspects of the kiosk style printing. The other modern printer dialogs such as "sys(1500,'_mfi_sysprint','_mfile')" will be used whenever full printer control is granted to the admin level users.

Thanks,
Stanley

 

[Olaf Doschke]

If there is a configuration in the .frx and I configure the report and tick the "save environment" checkbox, 1_which would be used? 2_if both, then who has priority? 3_if not both, then which one gets ignored?

There only is one. The checkbox merelynow finally is the UI for setting or emptying EXPR. So there is only one configuration.

As I said:

that also means the same EXPR field is still used for that and you can modify its content.

Bye, Olaf.

 

[Olaf Doschke]

In regard to the other part of your answer:

Well, obviously you never had to cope with 100 users in a bigger company each having different local printers and network printers.

You may not need multiple logical printers if you only need one configuration, but it pays to have one, which users are not allowed to change, so they can use the printer in other configurations otherwise with Word or Excel or any other application.

You most likely also never needed to adapt to some other printer brand.

Of course, stanlyn, a static situation never needs a change. But then it also doesn't matter which option you really choose. To be clear, once you choose the printer name option, even if it's only one, then you don't need to store anything in the FRX, the config options are totally under Windows control. You can still override some settings like ORIENTATION, but then you may change it for other usages, too, which becomes an annoyance for your customers.

One of the bad sides of saving printer environment is you do so at the development PC, your own PC, and the customer has another printer. That leads to what you describe: I modified the FRX from their selection of options listed here

You never need to, when you SET PRINTER TO NAME, they have the configuration at their control, no matter what they set, unless they change the printer name, will be what the VFP report engine will use.

Bye, Olaf.

 

[stanlyn]

Hi Olaf,


Well no, but coping with 34 different companies with 10-20 users each and hundreds of different printers, should qualify, shouldn't it?

Our users love our "set it and forget it" feature where each task is configured only once, and never the user never sees any further prompts, even after running many other totally different tasks that prints to different printers. They do not need to remember what printer the print job goes to.

The kiosk users doesn't have a clue as to the involved printers.

When we install our system at a new site, there is zero configuration for us. Their admin simply points each task's print job to their selected printer and they are done. There is no opening the report in its editor and do configs there. They can change their Word, Excel and any other Windows app's print job any way they like, and never have to set it back for our reporting to get it right every time. Furthermore, we really like to idiot proof these type of processes, as that eliminates support calls. From 1998 thru 2012, we have had zero support calls related to printing. Then we started getting printing issue calls from Win7 and W10, and that is why we are revisiting this issue. The original app is VFP7, and the rewrite is in W10, and this is where we are seeing a lot of behavior changes.


If I hear you correctly, I cannot use both for the same print job... However, I can still use the expr way when needed and the new "save config" way when it's functionality is needed. I can mix and match the two styles in the app???

Thanks,
Stanley

 

[Olaf Doschke]

Our users love our "set it and forget it" feature where each task is configured only once, and never the user never sees any further prompts, even after running many other totally different tasks that prints to different printers. They do not need to remember what printer the print job goes to.

The same goes for setting up the printer once and then SET PRINTER TO NAME...
It's your code doing so and not the user. So in the end it's just a one time configuration, too, and then the userscan forget. Just look back what I said. If you use the INIT of the FRX data environment to make the SET PRINTER TO NAME nobody has to do anything after the inital setupto run reports.

And one big advantage instead of hacking that config into the FRX is is, WHEN there come the need for a change, tha admin of your customer can simply use Windows to reconfigure the printer, instead of needing a VFP to hack the FRX once more or need you to do that.

But forget about that, if you don't understand it, stay with what you're used to. You should now know enough, you can still use a hack of the EXPR field of the first record of an FRX.

Bye, Olaf.

 

[Olaf Doschke]

If I hear you correctly, I cannot use both for the same print job... However, I can still use the expr way when needed and the new "save config" way when it's functionality is needed. I can mix and match the two styles in the app???

What?

You still have a totally wrong understanding of things.

Checking save printer environment means when you save the FRX the report designer saves the current printer configuration into EXPR, if it's unchecked that's not saved.

There still only is the one EXPR field, that stored printer config (some of it, not all as I already said).

The mechanism where what is stored has not changed a tid bit. It's just this option to uncheck it now making it easier for all the usual foxpro folks, who emptied that EXPR field to make a report independent on a certain printer.

And let me add a specific thing not working as stored into EXPR, I now tried that: I control a thermo printer which has a temperature setting influencing how saturated black is printed. To be able to scan printed barcodes it's essential this is correct. It's not read out from the printer and saved in an FRX, you also can't hack this in. As I said above: printers have become more complex. Most likely this configuration option is stored binary or wherever from the printer drivers. But since I can simply address this printer with its name installed for barcode printing, the inability of the FRX is of no interest to me. If you don't need any fancy advanced ocnfiguration, you may live with what you can hack into the FRX.

Bye, Olaf.

 

[Olaf Doschke]

Perhaps we shorten it this way:

1. You design your report, no matter what you do with the "save printer environment" option.
2. You hack the FRX as aftermath in the first records EXPR field

=> This works as it always has worked.

As you don't want to follow recommended practices, that' perhaps all you need to know.

Bye, Olaf.

 

[stanlyn]

Hi,

Thank you

I follow practices recommended by our customers, and especially for our kiosk customers we are certainly not following the recommended practices you are referring to. But that doesn't mean that I don't want to know how to implement those new ways, or how they differ...

Are you saying that SET PRINTER TO NAME some_printer_setting_name means SET PRINTER TO NAME HPLaserJet? It looks like you are not specifying a printer, but a setting like portrait/land, size, copies by using your mentioned "some_printer_setting_name" to the SET PRINTER TO NAME command. Is there an example of what the ini code would look like and an example on how to implement?

I get it that not all settings can be achieved via the expr field, especially with the more advanced printers and that is OK for our less advanced kiosk users.

Now for implementing configurations the new way... If I install the app at 100 sites, will I need to open and define each report's env for all 100 sites, OR just once at dev time with no further configuration once installed? Is it mandatory that I provide the report designer to each site? And yes, I do provide it, but is it mandatory to get the new way to work? Your answer on this will help me understand what is needed better.

Also confusing and I need more insight, How many named Windows printers do we need if the location has only one HPLaserjet printer and has 3 reports.
1. The invoice report is color=T, size=letter, orentation=landscape, simplex=T and copies=2,
2. The picklist report is color=F, size=letter, orentation=portrait, simplex=T and copies=1,
2. The ToDoList report is color=F, size=legal, orentation=portrait, simplex=F and copies=1,

Is there only one printer listed at the Windows level, or does there need to be 3 Windows printers, all using the same HPLaserjet driver with each having a different config matching each of the 3 reports? The solution I created many many years ago required only one Windows printer, and it would do all the setting changes on the fly and all automatically.

Stanley

 

[Olaf Doschke]

SET PRINTER TO NAME asks for a printer name, as you give it when installing the printer. You are free to name the printer, if you install the driver, are you aware of that?

I gave an example earlier, so please, just read more thoroughly:

So let's say you have an HPLaserjet with 3 printer trays and put in normal, high quality and label paper into the trays, then install the driver thrice and name it HPnormal, HPHQ and HPLabels and configure these three logical printers (all the same physical printer) to use paper tray 1,2, and 3.

So some_printer_setting_name simply means you choose a name, which states the physical printer AND the major setting like HPnormal, HPHQ, and HPLabels or let's say HPLaserJet_normalpapertray, HPLaserJet_HQpapertray, and HPLaserJet_labelpapertray. That's just a suggestion making life easier, you can also name the printer ERNIE and BERT if you like. And if you only need one configuration you can also use only one name, but I'd have one printer installation for multi-purpose, which users are allowed to use and change the configuration, simply the usual install, which already was done, and one installation for your specific name, which in your case might just be HPLaserJetFRX, is configured the way you need it and then ideally, if that works, locked by administrator to a) be available to users and b) not be configurable for them, thus you have your fixed settings as needed by the FRX.

You just have the same printer twice. Each printer icon in the Windows printers list means a different printer for Windows, even if it's the same physical printer you just installed it's driver twice or more times (actually the drivers might not really be installed multiple times, you just add a separate icon/shortcut into the Windows printer section), that's the "trick" behind it, Windows remembers the configuration you set to this specific logical printer. So simply setting to use that windows printer means you set the configuration in all the details the printer driver allows. Switching between HPLaserJet_normalpapertray, HPLaserJet_HQpapertray, and HPLaserJet_labelpapertray does stay at the one HPLaserJet printer, and rather switches between its configurations.

It doesn't matter how the configuration gets set, that's now not your task anymore, and you don't maintain it within the FRX. And whenever that perhaps needs some specific printer command like the thermoprinter temperature setting, you don't care how that's done, Windows does so via the printer driver.

And finally, once that's set up, you don't save printer environment, don't hack your FRX, but you add the SET PRINTER TO NAME "HPLaserJet_labelpapertray" for any labels report, and SET PRINTER TO NAME "HPLaserJet_normalpapertray" for normal reports, so this choice of the correct printer with correct settings is still embedded in the FRX and nobody needs to think about that or do anything manually.

In regard to label paper, I actually did an implementation in a large company, where they maintain printers twice with the normal name and with _label suffix. So if I need to print labels on label sheets, I determine the printer name with SET("Printer",2), if that doesn't end in "_label" I add that to the name and SET PRINTER TO NAME, then revert after printing. And this works, whatever tray actually is containing label sheets is their concern now, if I had a report with say TRAY=2 inside the EXPR memo, that would depend on label sheets always be in tray 2, while the way it is now, this can be in tray 2 on some printers, in tray 3 on others, it's always just a local convention where which paper has to go and each office or department with their own larger printer knows that for that office or department. They also have it in their hands (or their administrators hands) to configure the two PrinterName and PrinterName_label (the one with the _label suffix) printers with the correct trays used.

Bye, Olaf.

 

[Olaf Doschke]

About the second part: If you only switch settings you CAN store in EXPR, it can be easier to have them in the FRX, yes. It'll now just depend on the printer available to support color or whatever feature.

In regard of the admin overhead: In my sample case of the _label suffix, the company did all the secondary printer installations and I'm sure they found a way to do that easily without doing so for every single printer. There is Windows API function AddPrinter, for example...It was a one time step for them anyway.

And as I said, I may also have done it with TRAY=2, but you see even the settings you CAN store inside an FRX can become a pain in a large enough company with a variety of printers and differing common practices about tray numbers...

What makes no sense for me in your configurations is have size=legal or size=letter, without changing tray to real paper with these sizes, all you change this way may be margins. At leastI'm not aware of printer AI to know which paper tray has a certain paper size.

In the end as far as you now tell in detail besides the size issue our settings are easier to maintain without the need of multiple printer names in Windows, as you may have 0 admin work to do for that, but in fact it is just a metter of a few seconds going through the 3 steps of adding a printer manually.

Le me ask, because I actually don't know, because I never used your solution: When you do set color=T or F for your report, does that make all further prints color or black/white, when users print other documents from MS Word for example, so does that configuration stick? Or does VFP only set this once for the report printed?

I know, when they pick different reports within your application, the reports automatically adjust config for themselves, but how is the influence for any further printing on the system?

Bye, Olaf.