Hi,
I’ve got a problem when using MS XPS as default printet (used on server, no actual printing, only preview). For some List projects, the output is empty. I could post logs, if needed.
The workaround is to use Microsot OpenXPS Class Driver, hoping it would be working OK.
I’m using L&L 22, Windows Server 2012. But could be reproduce on Windows 7, 8.1.
I’m not aware of such an issue. Is this always reproducible with the same lists? Or does it happen once in a while? Does it only happen with the XPS Document Writer? Can you check to force the printer to XPS Document writer using LlSetPrinterInPrinterFile before printing to make sure there’s no other printer configuration present? Have you tried to delete any printer information files (*.lsp)?
Additionaly, a log file might be interesting to check.
Thanks for the reply,
I can reproduce it only with one .lst, which basically is just some values and sums() in footer, nothing fancy. It does only happens with “Microsoft XPS Document Writer”. I could try the LlSetPrinterInPrinterFile (but I’m middle in the release and don’t have time to tinker with sources, so I could try after the release), but there is only this one printer installed on the system, nothing else. There are no printer information files (*.lsp) present, just the .lst file.
I’m pasting end of the log. The log is huge and also contains some information I would rather not post in public forum. I could post you the message with the whole log.
▪;1000;04.01.2019 18:04:32.684;2;LL.API;4754;100:2=CMLL22♦101:1=2;<LlPrint() -> -998 (0XFFFFFC1A) (Aktuálny dátový záznam sa nezmestí na stranu.)
▪;1000;04.01.2019 18:04:32.684;2;LL.API;4754;100:2=CMLL22♦101:1=2;>LlPrint(2)
▪;1000;04.01.2019 18:04:32.684;1;LL.Printer;4754;100:2=CMLL22♦101:1=2; >OpenForEMF(page=59)
▪;1000;04.01.2019 18:04:32.685;1;LL.Printer;4754;100:2=CMLL22♦101:1=2; <OpenForEMF(page=59) -> 'Microsoft XPS Document Writer' (from 'Štandardné rozmiestnenie')
▪;1000;04.01.2019 18:04:32.685;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(Kontajner Výpisov (15.00mm, 14.00mm, 200.00mm, 279.00mm)): FINISHED
▪;1000;04.01.2019 18:04:32.685;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(Kontajner Výpisov (15.00mm, 14.00mm, 200.00mm, 279.00mm)): FINISHED
▪;1000;04.01.2019 18:04:32.685;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(___user_name___): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.685;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(___user_name___): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.685;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(IFOsoft): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.686;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(IFOsoft): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.686;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(Modul, datum tlace): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(Modul, datum tlace): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(Nazov zostavy): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(Nazov zostavy): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; >OBJSTATE(Client, Strana): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;1;LL.ObjectStates;4754;100:2=CMLL22♦101:1=2; <OBJSTATE(Client, Strana): WAITINGFORPRINT
▪;1000;04.01.2019 18:04:32.687;2;LL.API;4754;100:2=CMLL22♦101:1=2;<LlPrint() -> 0 (00000000)
▪;1000;04.01.2019 18:04:32.687;2;LL.API;4754;100:2=CMLL22♦101:1=2;>LlPrintEnd(2,0)
▪;1000;04.01.2019 18:04:32.688;2;LL.Notification;4754;100:2=CMLL22♦101:1=2; >@NOTIF.(code= 87, param=0X00000032, user=0X003ABDEC)
▪;1000;04.01.2019 18:04:32.688;2;LL.Notification;4754;100:2=CMLL22♦101:1=2; <@NOTIF.(code= 87) -> 00000000
▪;1000;04.01.2019 18:04:32.688;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000011, lp=0X00000032 stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.688;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 1
▪;1000;04.01.2019 18:04:32.697;2;LL.Notification;4754;100:2=CMLL22♦101:1=2; >@NOTIF.(code= 87, param=0XFFFFFFFF, user=0X003ABDEC)
▪;1000;04.01.2019 18:04:32.697;2;LL.Notification;4754;100:2=CMLL22♦101:1=2; <@NOTIF.(code= 87) -> 00000000
▪;1000;04.01.2019 18:04:32.697;2;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >LsBLOBManagerAdd(0X15A078F8)
▪;1000;04.01.2019 18:04:32.697;2;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <LsBLOBManagerAdd() -> 0X00000001
▪;1000;04.01.2019 18:04:32.697;2;LL.Generic;4754;100:2=CMLL22♦101:1=2; Info: OpenStorage(ReportParameters,False) failed: ReportParameters could not be found. (80030002) (may be expected and handled)
▪;1000;04.01.2019 18:04:32.697;2;LL.Generic;4754;100:2=CMLL22♦101:1=2; Info: OpenStorage(ColumnSortInfo,False) failed: ColumnSortInfo could not be found. (80030002) (may be expected and handled)
▪;1000;04.01.2019 18:04:32.698;2;LL.Generic;4754;100:2=CMLL22♦101:1=2; Info: OpenStorage(ExpandedRegions,False) failed: ExpandedRegions could not be found. (80030002) (may be expected and handled)
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000002, lp=0X003A9BA4 stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 0
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000024, lp=00000000 stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 0
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000012, lp=00000000 stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 0
▪;1000;04.01.2019 18:04:32.698;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000002, lp=0X003A9BDC stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.699;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 0
▪;1000;04.01.2019 18:04:32.699;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000002, lp=0X003A9BB0 stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.699;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 0
▪;1000;04.01.2019 18:04:32.702;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: >event(0X15C38D90): m=c6e3, wp=0X00000011, lp=0XFFFFFFFF stg=0X18C281D8
▪;1000;04.01.2019 18:04:32.702;1;LL.API;4754;100:2=CMLL22♦101:1=2; LS: <event(0X15C38D90): m=c6e3 -> 1
▪;1000;04.01.2019 18:04:53.703;1;LL.Licensing;4A30;100:2=CMLL22♦101:1=6; [clsLicenseInfo] thread: 0X07D90000: 'YYY:XXX'
▪;1000;04.01.2019 18:04:53.703;1;LL.Licensing;4A30;100:2=CMLL22♦101:1=6; [clsLicenseInfo] thread: 0X07D90000: 'YYY:XXX'
▪;1000;04.01.2019 18:04:53.703;1;LL.Licensing;4A30;100:2=CMLL22♦101:1=6; [clsLicenseInfo] thread: 0X07D90000: 'YYY:XXX'
▪;1000;04.01.2019 18:04:53.703;1;LL.Licensing;4A30;100:2=CMLL22♦101:1=6; [clsLicenseInfo] *********************************
Thank you
Sure, feel free to DM me with the full log for a first quick glance. From the log file, it seems as if the actual conatiner had finished printing while a couple of other objects haven’t even started (maybe due to appearance conditions). However, it wouldn’t make much sense if this was printer dependent.
A preview file and the project file might also help, although I’d suggest to make sure all GDPR regulations are met, thus you should rather raise a normal support request where a data processing agreement is part of our standard procedure.
Just to keep this thread updated - @Jozef_Iljuk will try to reproduce the issue with LL24 to see if it still exists. He’s suspecting the TotalPages$() two-pass logic to be the culprit. From the log and project file, we were unable to trace down the problem, unfortunately. If LL24 still has an issue here, we’ll hand the case over to our support team for a quick remote session to see what’s happening.
Hi Jochen,
finally had some time to test it with L&L 24 and IT IS working there. Also I can confirm, that using “Microsot OpenXPS Class Driver” does solve the problem with L&L 22 - has been tested for about 2 weeks with no problem so far.
Enjoy your weekend 
I sure will enjoy mine… working 
Thanks for following up on this. Good to hear you’ve found a working solution for LL22 as well. Hope you find some time off despite working 
. Don’t hesitate to return here anytime we can help.
Haha It’s me again 
Today I encoutered the same problem but now with “Microsot OpenXPS Class Driver” What is intereseting, is that when using “Microsot XPS Document Writer" there is no problem But the most interesting part is, that it is the always same .lst. I’ve tried with the real printer, no problem there.
So I had a close look on L&L debugger logs and find, that before the last page print, there is page break, because there isn’t enough space. So I looked at the .lst and there are 2 text items linked to the Container, which are printed “after the container, preserve size”. So I think that MAYBE the linked objects are causing something bad. When I removed these two objects, everythin is OK, yes, but I think this is because no page break could occur and therefor it is really different situation. Then I put back the removed objects and resized the container a bit to the smaller size and now it is working right and the output is the same as I’ve tried with the real printer.
So I’m still puzzled. It’s interesting that from 47 .lst files that are printed daily, only this one is having problem and only in certain circumstances. Maybe I should start looking for some OSS virtual printer for windows as I really DON’T trust the MS stuff, anyone has some suggestions?
Thank you