Default printer and application startup

[GoranBru]

Hi,
we have encountered on interesting problem related to some new printers, namely Konica Minolta 235 and (today) HP Envy 6100e. The problem is that if the default printer is set to any of these two printers the software could not start up. The first time I investigated the problem and spent almost 6 hours on it I was always lost in RichView/ScaleRichView units that were initialising on startup. And the program simply hang up, no error, no program. So I had to kill the software. I tried other our programs which do not use RV/SRV and they started normally. When we set the default printer to something like "Microsoft print to PDF", the software started normally. We use Delphi Sydney, TRichView version 22.4 and TScaleRichView version 12.3.

Has anybody encountered similar problem and how did You resolve it?

Best regards,
Goran

[Sergey Tkachenko]

Does the problem happen somewhere in the initialization of units? I mean, before the first line in the project file (usually Application.Initialize;) is called?

As far as I can see, TRichView, RichViewActions and ScaleRichView do not have printer-related code in the initialization sections.
For TRichView, you can turn on initialization logging.
The application must be compiled with RVLOG compiler $ddefine.
The log file's path is defined in RVLogFile constant in RVFuncs.pas, the default value is 'c:\Components\TRichView\Logs\log.txt'.

[LS_M]

I have observed a similar phenomenon that in our case has to do with the printer. Don't know for sure if it has to do with RichView, but only in software with RichView does this problem occur that the software doesn't start. Most of the time after Windows updates there is an exception and the program does not start.
The solution is this. Open settings -> printer to scanner -> if your default printer is Canon xxx -> choose another printer and make it the default printer -> then set the Cannon as the default printer again. I know this is not really a solution but al least the software will run.
This seems counterintuitive but works in my case. Windows seems to still store printer information somewhere else. The biggest problem is that this behaviour has never occurred here in house and we haven't had the opportunity to debug it yet. This printer problem rarely occurs only to some customers. I'm not sure if this applies to your problem but it might be worth a try.

- HL

[Sergey Tkachenko]

Tests that may help to understand what happens.

1. Try running the application without TRichView but with TPrintDialog. Probably, any VCL application that uses printer has this issue.
2. Put a breakpoint in the project file (*.dpr) on the line Application.Initialize. If this breakpoint is reached, the problem happens not in unit initialization, but in the form creation.
3. Compile your application with "debug dcu" compiler option (to allow debugging system VCL units). Put the breakpoint in TPrinter.GetPrinters and TPrinter.SetToDefaultPrinter (Vcl.Printer.pas) and try to trace the execution when this breakpoint is reached. The most probably, the freeze is in these functions.

[GoranBru]

Hi Sergey,
in our case it happened only twice while we have hundreds of installations around. As far as I have traced the startup procedure it happened after the line "Vcl.Forms.Application.Initialize;" in dpr but before any form or datamodule creation. We do not have any form creation in dpr but in a special unit.
Removing RV/SRV from project is absolute no-go but the idea of initialization logging is something we'll definitely try. Thank You for the tip, at least we can now continue our investigation.

Best regards,
Goran

[Sergey Tkachenko]

Unit initialization (i.e., code in "initialization" sections of units) is executed before running any code from dpr file.
So, if the problem occurs after calling Application.Initialize, this means initialization of all units was completed successfully.

If the problem occurs after calling Application.Initialize but before calling any form's OnCreate event, this means that the problem is in component creation or DFM loading.

My guess that the problem may occur when any component tries to access the printer properties. It may be TRichView, ScaleRichView, or VCL components like TPrintDialog. The main code that calls OS functions for printers is in TPrinter.GetPrinters and TPrinter.SetToDefaultPrinter, what's why I suggested to trace them. TRichView and ScaleRichView just use TPrinter's methods.

[LS_M]

Running the application without RichView will get us nowhere because as I said it happens only very rarely at the customers side we never had a chance to track it down in house. At least we are happy to give a solution to the customer with the printer switch. It is not a satisfactory manner but at works for us so far until the next Windows Update. Sorry for not being really helpful.

- HL