Use of API in Standard License

[Carlos_Torres_Cano]

Hi,

I currently have a List&Label Standard licence and I am trying to change the way my project works, moving from TListLabel30 VCL visual components to using the API directly to have more control, but I cannot get any Jobs to open with LlJobOpen (always returns error -101). Is it possible that the use of the API is limited somehow in the Standard version?

Sorry, but I have not been able to find any information on this.

Thank you very much.
Carlos Torres.

[tmetternich (combit Support - Thomas Metternich)]

Hi,

We would recommend using the FireDAC component, as it is much more convenient. What are you missing here? Programming with the API is more tedious. Please try opening LlJob with “CMBTLANG_ENGLISH.”

[Carlos_Torres_Cano]

Hello, thank you for your reply.

The reason for migrating to API functions is that I need to have dynamic control over the loading and unloading of the DLL, and from what I have found, the use of visual components makes this loading automatic and does not allow manual unloading.

I need to have that control over the DLL because, when processing batches of thousands of labels (even if done in blocks), it seems that the list&Label engine freezes after a few hours, blocking the execution of the software.

I had thought that, instead of using the VCL visual components, if I use the API, after each block of labels I can completely restart the components and the DLL itself, to not overload the engine.

Regarding CMBTLANG_ENGLISH, that is precisely how I was opening it, and it keeps giving me error -101.

I tried the solution in this link:

HOWTO: Loading the List & Label DLLs Dynamically in C/C++ and Delphi

Valid from List & Label 8 Often it would be useful to load the List & Label DLLs dynamically at runtime when they are actually needed (decreases memory usage, improves appliction's startup time, etc.). To make this comfortable for the programmer we have provided special declaration files for C/C++ and Delphi which can be find in your List & Label installation. To implement dynamic loading of List & Label you only need to perform a few simple steps (replace "??" with the corresponding List & Lab…

But I couldn’t find the .PX files mentioned in the link.

That’s why I wondered if this approach was limited in the Standard Edition.

[tmetternich (combit Support - Thomas Metternich)]

Hi,

Due to error “-101.” This means that List & Label cannot load the corresponding language file (cmLL3001.lng). Can you use Debwin to check where the language file is trying to load from?

Debwin log:

1. Close the application.

2. Start the debug tool “Debwin4.exe” from the LL installation directory (folder “Miscellaneous”).

3. Select “Capture List & Label Log” in Debwin4.

The file for dynamic loading should be cmbtLL30x.pas. However, FireDAC VCL already loads this dynamically.

[Carlos_Torres_Cano]

Thank you, between the cmLL3001.lng, the code in cmbtLL30x.pas and Debwin4’s analysis, I have managed to launch the first job without errors.

But, unfortunately, this has not solved my problem. The reason for migrating to the API is to be able to completely unload CMLL30.dll so that it can be restarted every x iterations.

The problem I encounter is that, using the Microsoft WinDbg tool to analyse the loaded libraries, I find that no matter how many times I call LL30xUnload, CMLL30.dll always appears loaded, with a LoadCount of at least 1, never 0.

If I load the DLL and, without starting any work, unload it, it unloads completely and no longer appears among the DLLs associated with the process, but if I open and close a single job, even if I don’t print anything with it, the CMLL30.dll library can no longer be completely unloaded using LL30xUnload, but always remains pending with a LoadCount = 1.

Is there any way to release it that ensures that it has indeed been completely unloaded?

Or, if this is not possible, is there any way to completely restart the List&Label engine without having to close the process that started it?

Again, the problem I am trying to solve with all this is that, in processes where it has to export thousands of labels, it freezes.

I believe the reason is that the GDI handles are not released properly between prints, as according to the Debwin4 log I find that the GDI handle count reaches over 5700 before freezing and the process stops just when it is creating one of the objects of the next label to be printed…

Can you help me with this?

Thanks again and best regards.

Carlos Torres.

[tmetternich (combit Support - Thomas Metternich)]

Hi,

Unfortunately, this question can not be solved in the forum. We need additional information that cannot be exchanged through the forum platform.I’d suggest to open a support case via our support portal at https://www.combit.net/en/support-center/. Please copy any pertinent information from this thread into the case description.

[Carlos_Torres_Cano]

Ok, thank you very much. I will proceed to open a support case.

Best regards.

Carlos Torres.