We are reaching out to request assistance with a big issue we’re encountering while using List & Label version 30 in WinForm Application.
Specifically, we are trying to force the report to print in A5 page format, but despite setting the related parameters in code, they don’t seem to be taken into account.
Below is a snippet of the VB.NET code we’re using:
Could you kindly advise us on the correct way to apply these settings, or suggest any steps we might be missing?
We’re happy to provide further technical details if needed.
Thank you in advance for your support.
crauchfuss
(combit Support - Christian Rauchfuß)
2
Hi Federico,
welcome to the List & Label forum!
The paper format is hard-coded in the report. To change it, the report must be opened via the DOM API, the format must be set, and then saved. The code for this is quite simple:
Using LL As New ListLabel()
'Create a new ProjectList
Dim proj As New ProjectList(LL)
'Open your report, the 3rd parameter allows you to open the report without datasource
proj.Open(report, LlDomFileMode.OpenOrCreate, LlDomAccessMode.ReadWrite, True)
'Set the paper format to A5
'"Region" is a zero-based index
proj.Regions(0).Paper.Format = "11"
'Set the Orientation to Portrait
'1 - Portrait
'2 - Landscape
proj.Regions(0).Paper.Orientation = "1"
'Save and close the Report
proj.Save()
proj.Close()
End Using
A list of all valid formats can be found at Microsoft here Paper Sizes.
Hi Federico welcome to the forum.
You can use LL.Core.LlSetPrinterInPrinterFile() to set all printerconfigurations.
e.g. something like that
PrinterSettings printerSettings = new PrinterSettings();
PageSettings pageSettings = new PageSettings(printerSettings)
{
Landscape = true
};
foreach (PaperSize paperSize in printerSettings.PaperSizes)
{
if (paperSize.Kind == PaperKind.A4)
{
pageSettings.PaperSize = paperSize;
break;
}
}
LL.Core.LlSetPrinterInPrinterFile("yourlist.lst", printerSettings);
You also can use the DOM to modify the regions in the project (but only for size , printername and orientation, further devmode configs must be set with LlSetPrinterInPrinterFile methode)
However, in my case the requirement is slightly different:
I need to control the paper format (A4 or A5) dynamically at runtime, depending on certain conditions in the application.
That’s why I prefer not to configure the paper format directly in the .lst file, and I’ve also removed the .lsv files to prevent them from overriding any programmatic settings .
The goal is to set the paper format via code, right before export or printing, without modifying the report project file.
If there’s a way to force A4 or A5 formatting through the API during runtime (as done in other print libraries), that would be ideal.
Hi Erdal,
thank you very much for your detailed response and warm welcome!
The solution with LlSetPrinterInPrinterFile() is indeed useful when you want to persistently configure the printer settings inside the .lst file itself. However, in my case, I need a non-persistent solution. I have to set the page format (for example, A5 portrait) dynamically at runtime, depending on the context of the application, and without modifying the project file or saving changes to it.
Since the reports are shared and reused in different scenarios, I cannot alter the .lst file each time, nor can I assume a specific printer configuration. That’s why I’m looking for a programmatic and temporary configuration, ideally one that is applied only during the current print or export job, without affecting the base report.
Thanks again for the DOM suggestion. I will keep it in mind for other use cases where persistent changes are acceptable.
Instead of persisting the DOM to the project file you can make your changes in memory while printing. This needs to be done in the DefinePrintOptions event.
Replace proj.Open() in the sample code by proj.GetFromParent(). You don’t need to Save() and Close() the DOM in this case.
AFAIK there are no means to determine the current project type in DefinePrintOptions. If you use the same code to print list, card and label projects you might need to somehow decide whether to instantiate ProjectList, ProjectCard or ProjectLabel.
I tried your solution, but I’m getting the following error:
“An attempt was made to call a function which is not covered by the license.”
Even though I correctly passed the license information using:
LLs.LicensingInfo = “…”
right after the Using statement.
Do you have any idea what might be causing this?
Best regards,
Federico
crauchfuss
(combit Support - Christian Rauchfuß)
8
Hi Federico,
using the DOM-API requires at least a List & Label Professional Edition. The Standard Edition does not cover that feature.
Nevertheless, if the page size is to be adjusted dynamically, then all objects contained in the report must also adjust their size accordingly. This means that a report created in A4 format cannot simply be printed in A5 format, as the objects have fixed coordinates and heights/widths. These would also have to be adjusted.
Another solution might therefore be to use two separate report files – one for A4 and one for A5 – and then use either one or the other for printing/exporting?
Following your suggestion, I created a new .lst report file with the layout configured for A5 format and set the printer to Microsoft PDF. The formatting works as expected now.
However, I would now like the report to use the system default printer instead of the one saved in the report (Microsoft PDF), since I need to print dynamically to different printers depending on the context.
Here is a simplified extract of the VB.NET code I’m using:
Using mainDataProvider As New AdoDataProvider(dataSet)
LL.DataSource = mainDataProvider
LL.AutoShowSelectFile = False
LL.AutoShowPrintOptions = False
LL.Print(LlProject.List, "report.lst", False, LlPrintMode.Normal)
End Using
How can I ensure that the print job uses the current default system printer, instead of the one defined in the report?
Thank you in advance for your help.
Best regards,
Federico
1 Like
crauchfuss
(combit Support - Christian Rauchfuß)
10
Hi Federico,
I’m glad to hear it’s working for you.
Using the default printer is pretty simple. When List & Label starts printing, it checks if the *.lsp file is available, and if it is, it tries to use the printer listed in there. If the *.lsp isn’t there, List & Label has a fallback to use default printer of the system. Here’s a diagram of how it works: List & Label Files
LL.AutoShowSelectFile = False
LL.AutoShowPrintOptions = False
LL.AutoProjectFile = report
'Delete the *.lsp file to use the default printer of the system - replace "LL.AutoProjectFile" with your report file'
LL.Core.LlSetPrinterToDefault(LlProject.List, LL.AutoProjectFile)
LL.Print()
Goodmorning,
As you can see, it doesn’t work; printing is interrupted (generating exception). I think it’s a bug.
Or maybe Standard Edition dont support LL.Core instruction?
Federico
crauchfuss
(combit Support - Christian Rauchfuß)
12
This has to work. I can provoke the behavior - but only if I cancel the file save dialog (from Microsoft Print to PDF, which is default printer on my system) - and in that case it’s okay because I’m canceling the print process (i.e., saving the PDF). Maybe it helps to activate the print dialog (LL.AutoShowPrintOptions = True) and check what printer is used in that moment. Is it the expected printer?
Otherwise a Debwin log file could help and provide more information about what’s going on in the background. Just start “Debwin4.exe” from …\combit\LL30\Miscellaneous and choose “Capture List & Label log” before running your application.
Just one idea: Windows often crashes the party. In the printer setting of Windows there is a property called “Let Windows manage my default printer”. If it is checked, then Windows automatically sets the last printer used to the default printer of the system and so the behavior could be different from the expected behavior.
crauchfuss
(combit Support - Christian Rauchfuß)
13
But that’s is exact the behavior that is caused by “LlSetPrinterToDefault”. The “p-file” is deleted and List & Label is using the default printer. That’s what you asked for
I have shared a screen recording and the related logs with you via private message.
Thanks
Federico
crauchfuss
(combit Support - Christian Rauchfuß)
15
I would like to conclude this thread by adding that a cause was found and solved. Unfortunately, an endless loop led to a cancellation in the background.
