Skip to main content

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

Hi Tony,

This is a known issue that Development is already working on. I'm guessing that will be resolved for the 10.1 release.  Of course the workaround of modifying your programs to use WIN$PRINTER will increase the odds of your program continuing to work with future Windows releases.

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

Thanks Doug - as we continue looking at this issue, we are finding that the -Q DUMMY does work just fine on some Windows 10 computers,but not on others; we're also finding that the WIN$PRINTER option to WINPRINT-GET-NO-PRINTERS also sometimes works on Windows 10 and sometimes does not.  We've tested with both Extend 9.1 and 10.0 runtimes.

On the computer where printing does NOT work, either with WIN$PRINTER or with the -Q DUMMY option, we are able to print from other WIndows applications just fine.

What could cause the WIN$PRINTER call, using WINPRINT-GET-NO-PRINTERS to not work on Windows 10?

Tony

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

Hi Tony,

When things work on one PC and don't on another I first suspect permissions.  On the failing PC right-click on the shortcut that launches the app and select 'Run as administrator'.  If it still fails then capturing Process Monitor logs of a run on a good PC and a run on a bad PC might be helpful. Comparing those may reveal clues.

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

Hopefully, this may help ...There appears to be a "feature" of Windows 10:)  After doing some more research I found information that some versions of Windows 10 have a switch called  "Let Windows manage my default printer".  When turned on, the default printer is the last used printer.  Here is a link to explain this "feature" and how to turn

it off:

www.tenforums.com/.../26138-printer-turn-off-let-windows-10-manage-default-printer.html

Or just do a Google search for:

 "How to Turn On or Off Let Windows 10 Manage Default Printer"

Here is a summary:

Open Settings->Devices->Printers&Scanners(on the left side)

On the right side there should be a section that says:

 Let Windows manage my default printer

With a switch below it that you can turn off.

Hi;

We're using Extend 9.2 but have also tested with Extend 10.0, on Windows 10.  We have a line in the config file set as PRINTER -Q DUMMY - in previous versions of Windows, we open file with name "PRINTER" for output, and print a report to it.  The -Q line pointing to a non-existent print queue triggered Windows to pop a GUI box which allowed the user to select the printer they wish to use for the report.

On Windows 10, this no longer works.  Rather, opening a file with the name "PRINTER" causes the runtime to lock up.

This had been a problem when Windows 7 was released, and was reported as incident 2513602, and was fixed in version 9.1 of the runtime, and I believe also released as ECN 3824 for version 8.0.

Is there a fix to make this work on Windows 10, or must we modify all the old legacy reports to make use of WIN$PRINTER?

Thanks

Tony

I had checked the suggestion re letting Windows manage the default printer, and that option was already off.  However, it turns out the "locking up" problem, using both -Q DUMMY and using WIN$PRINTER, was caused by a printer that I had set up when onsite at a customer site.  Of course, that printer was not available to Windows, and when I removed that specific printer from my Windows devices, and only removed that one printer - the problem with locking up went away.  Now, the WIN$PRINTER call to get the list of printers work, and so does the -Q DUMMY option for the legacy reports.

Terms & ConditionsAccessibility statement