4D not getting Current Printer in Windows TS

4D client v16, and v17
MS Windows RDS terminal serving, Server 2008r2, fully patched

Short story:
4D client, running in MS Windows RDS (terminal server) often has problems detecting the current printer.

We use a 3rd party product called “TS Print” (as in “Terminal Server” print – by TerminalWorks). Often, when 4D client launches it doesn’t get a current printer (about 25% of the time). When I say “it doesn’t get a current printer”, I mean
The Get current printer command returns a null string
GET PRINTABLE MARGIN Returns all zero’s

4D is seeing a list of printers (with the PRINTERS LIST command), but just doesn’t get a current printer.

I’ve tried using the SET CURRENT PRINTER command, but it doesn’t fix the problem. I executeSET CURRENT PRINTER to a printer that is listed in the current printer list, but when I read Get current printer again, I still get a null string

However, if we launch Notepad in the same user session, we are typically able to see the user’s current printer, and print.

If Notepad can get a current printer, and print, why can’t 4D?

I have exactly the same problem on some of my installations, but none of them are on TS (we use Citrix) so this may not work for you.

I’ve wrapped SET CURRENT PRINTER so that it will call GET CURRENT PRINTER to check that it has been changed to the correct printer. It tries 5 times, and then gives up if the correct printer still isn’t set. If it doesn’t happen on the first try it logs how many attempts it takes. I just checked a log, and it has lots of entries for multiple retries recorded, so it’s a pretty common situation in my experience.

I heard about similar cases.
It seems (seems because I don’t know) that it was kind of strange setups of terminal server in combination with network printers in combination with authentication.

When 4D was launched, there was sometimes the standard printer for this terminal client session not yet ready, because of authentication or network issues, don’t know.

4D behaves as if there was no standard printer at all or the standard printer is damaged.
Often this can be “fixed” by quit and restart of 4D (just 4D, not for the terminal session, then the lottery starts again).

Usually we ask the customer to check the authentication/network sessions, to be sure that the standard printer is setup correctly - or early enough. At least before 4D launches.

A workaround which seems to help is to set the default printer manually.
If you have access to such a terminal client you could try that. Orchard’s Win32API has commands to get the system standard printer (which is not the current printer in 4D, as this can be DIFFERENT from the system printer).
If you use 4D’s Set current printer, it changes the printer only for 4D, allowing you to print somewhere else, without impacting the user just trying to print with Notepad.
If you use systems current printer, it changes the printer for all applications.

So use Win32API (or via batch process other tools) to change the system printer. Wait some seconds, then try with 4D again.

As said, this is just “seems”.

As reminder, not related at all with your question:
MS Windows RDS terminal serving, Server 2008r2, fully patched

Windows Server 2008r2 is very close to end of life.
You need to replace it in the next 6 months anyway and migrate at least to 2012, better 2016/2019.
As this problem seems to happen only for very small group of customers and these all seems to use older versions, maybe that will solve the issue as well.

Thanks Thomas,
I have Win32Api installed (for other purposes): I’ll give that a try.

I agree with Peter.

On some TS we also need to set the printer inside a repeat loop with a delay.
The problem starts with windows xp where the first printer switch always fails.
Also we set the system printer with win32 API

at startup.
check system printer -> get and set with win32API
then check the 4d printer and use it inside a loop with an exit point if the switch fails after x time. we try it max 50 times. (have not logged it like Peter)

And for network printers it is a good idea to use the printer IP address and not \Server\Printer…
Same for mapped network drives

Most problems fixed for some days if the DNS server gets a restart.